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Abstract 


The  Defence  Research  and  Development  Canada  (DRDC)  Centre  for  Operational  Research  and 
Analysis  (CORA)  is  developing  capability-engineering  analysis  tools  to  support  the  building, 
demonstration,  and  analysis  of  executable  architectures.  Our  previous  paper  [7]  described  how  to 
model  workflows  within  an  Operations  Centre  (OPCEN)  employing  a  Net-Centric  architecture.  It 
used  a  State  Machine  (SM)  to  simulate  how  multiple  jobs  can  proceed  in  parallel,  and  in 
contention  within  priorities,  when  operators  use  a  Task,  Post,  Process,  Use  (TPPU)  cycle  to 
organize  their  work. 

This  paper  extends  the  OPCEN  SM  model  to  track  the  interaction  of  work  between  OPCENs.  The 
State  Machine  of  Federated  Nodes  (SMOFN)  engine  is  organized  around  networked  functional 
nodes  within  those  OPCENs  that  produce  and  consume  products  held  in  a  virtual  Repository.  The 
data-driven  simulation  uses  files  to  build  customized  job  workflows  and  configure  any 
combination  of  nodes  without  affecting  the  operational  logic. 


Resume 


Le  Centre  d’ analyse  et  de  recherche  operationnelle  (CARO)  de  Recherche  et  developpement  pour 
la  defense  Canada  (RDDC)  est  en  train  de  developper  des  outils  d’analyse  pour  l’ingenierie  des 
capacites,  a  Tappui  du  developpement,  de  la  demonstration  et  de  Tanalyse  d’architectures 
executables.  Dans  notre  document  precedent  Erreur  !  Source  du  renvoi  introuvable.,  nous 
decrivions  comment  modeliser  les  flux  de  travaux  dans  un  Centre  des  operations  (CENOP) 
utilisant  une  architecture  reseaucentrique.  Le  modele  faisait  appel  a  une  machine  a  etats  pour 
simuler  comment  des  taches  multiples  peuvent  etre  executees  en  parallele,  et  en  cas  de  conflit 
dans  les  priorites,  lorsque  les  operateurs  utilisent  un  cycle  TPPU  (tache,  affichage,  traitement  et 
utilisation)  pour  organiser  leur  travail. 

Dans  le  present  document,  le  modele  de  machine  a  etats  des  CENOP  est  elargi  et  permet  de  suivre 
Tinteraction  des  taches  entre  les  CENOP.  Le  moteur  de  la  machine  a  etats  de  nceuds  federes 
(SMOFN,  de  l’anglais  State  Machine  of  Federated  Nodes)  est  articule  autour  de  nceuds 
fonctionnels  en  reseau  dans  ces  CENOP,  qui  generent  et  consomment  des  produits  dans  un  depot 
virtuel.  La  simulation  dirigee  par  les  donnees  a  recours  a  des  fichiers  pour  creer  des  flux  de 
travaux  personnalises  et  configurer  une  combinaison  de  nceuds  sans  nuire  a  la  logique 
operationnelle. 
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Executive  summary 


Executable  Architecture  of  Net  Enabled  Operations:  State 
Machine  of  Federated  Nodes: 

M.G.  Ball;  R.W.  Funk;  R.  Sorensen;  DRDC  CORA  TR  2009-012;  Defence  R&D 
Canada  -  CORA;  November  2009. 

Background:  The  Defence  Research  and  Development  Canada  (DRDC)  Centre  for  Operational 
Research  and  Analysis  (CORA)  Joint  Studies  Operational  Research  Team  (JSORT)  has  been 
engaged  in  several  efforts  to  model  processes  within  the  realm  of  Command,  Control,  Computers, 
Communications,  Intelligence,  Surveillance  and  Reconnaissance  (C4ISR).  Through  this  work,  it 
became  apparent  that  the  ability  to  interrupt  jobs  in  favour  of  higher  priorities  created  a  unique 
challenge  because  it  could  not  be  modelled  using  classical  sequenced  activity  diagrams.  The 
chosen  solution  was  to  create  a  model  of  an  operations  centre  (OPCEN)  using  the  approach  of  a 
state  machine  (SM),  which  is  defined  in  [4]  as  “any  device  that  stores  the  status  of  something  at  a 
given  time  and  can  operate  on  input  to  change  the  status  and/or  cause  an  action  or  output  to  take 
place  for  any  given  change.”  This  led  to  the  development  of  the  OPCEN  SM  described  in  [5] 
through  [8], 

The  SM  of  Federated  Nodes  (SMOFN)  engine  includes  all  of  the  functionality  of  the  OPCEN  SM 
and  expands  on  it  to  account  for  interactions  between  several  OPCENs  operating  collectively 
through  a  Net-Centric  Architecture.  It  also  adds  the  capability  to  simulate  all  aspects  of  OPCEN 
work  beyond  simply  creating  products.  These  expansions  form  the  basis  of  the  report. 

Developing  the  SMOFN  engine:  The  OPCEN  SM  has  been  extended  to  account  for  Net-Enabled 
interactions  between  several  OPCENs.  In  essence,  the  OPCEN  SM  accounted  for  the  work  done 
by  a  single  OPCEN  to  produce  several  products  based  on  data  analysis.  In  the  SMOFN,  not  only 
are  such  production  jobs  tracked  within  several  OPCENs,  but  the  products  they  create  are 
uploaded  to  a  common,  networked  Repository  so  that  all  products  can  be  accessed  and  used  by 
any  OPCEN.  The  SMOFN  engine  is  an  attempt  to  capture  the  essential  logic  that  governs  the  way 
work  is  conducted  anywhere,  but  with  particular  emphasis  on  ensuring  that  it  can  be  fully  applied 
to  integrated  activity  between  networked  OPCENs. 

Because  the  OPCEN  SM  concentrated  on  job  production,  most  of  the  SMOFN  development 
concentrated  on  adding  the  effect  of  nodes  outside  of  the  Producer,  as  well  as  creating  the 
interfaces  between  all  of  the  nodes.  Including  the  Producer,  there  are  five  nodes,  or  types  of 
activity,  accounted  for  within  the  SMOFN,  and  each  has  a  unique  activity  set  which  they  are 
responsible  for. 

1.  The  Producer  generates  products  from  available  data  inputs; 

2.  The  Consumer  receives  products  which  it  uses  to  maintain  situational  awareness  (SA).  It 
may  generate  questions  and  send  them  to  the  Discover  activity; 
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3.  Discovery  receives  questions  from  the  Consumer  and  searches  to  see  if  they  can  be 
answered  using  available  information.  Discovered  information  is  passed  to  the  Producer  and 
missing  information  is  requested  from  External  Sources; 

4.  The  External  Sources  activities  receive  queries  and  send  new  data  to  the  Producer;  and 

5.  The  Repository  stores  information  and  acts  as  a  medium  for  the  other  nodes  to  communicate. 

Populating  the  SMOFN  engine:  The  primary  advantage  of  the  SMOFN  is  that  the  model  itself 
is  only  concerned  with  the  execution  of  the  logic.  All  operating  parameters,  such  as  the  number  of 
operators  at  an  OPCEN  and  their  skill  sets,  or  the  number  of  jobs  to  be  done,  are  read  from  data 
files  during  the  setup  stage  of  the  simulation.  This  data  must  be  representative  of  the  operating 
parameters  of  the  modelled  OPCENs,  as  the  goal  is  to  accurately  simulate  data  flow  between 
these.  Particular  emphasis  is  placed  on  describing  job  threads  that  involve  multiple  OPCENs, 
such  as  the  process  to  report  and  respond  to  events  in  theatre  or  the  preparation  of  high-level  daily 
briefs.  Another  major  component  is  the  composition  of  various  OPCENs,  as  far  as  the  number  of 
operators  on  shift  and  the  skills  they  are  trained  in.  Although  much  of  this  data  will  be  classified, 
the  SMOFN  engine  itself  remains  unclassified  as  it  is  saved  in  a  separate  file  from  any  data  which 
it  would  read  upon  execution. 

This  work  starts  with  the  analysts  converting  whatever  evidence  exists  (typically  documentation 
or  verbal  descriptions  from  operators)  of  the  current  Command  and  Control  (C2)  practices  into 
model  form.  In  theory  these  should  be  Standard  Operating  Procedures  (SOPs)  that  execute  as  a 
thread  from  start  to  finish.  The  actual  experience  is  that  most  SOPs  tend  to  be  incomplete  or 
inaccurate  so  their  logic  will  not  actually  execute  as  described.  The  knowledge  gained  through 
previous  work  with  the  SMOFN  engine  is  used  to  address  these  gaps  so  that  the  modelling 
process  eventually  captures  fully  executable  threads.  Not  only  can  these  threads  be  recreated  as 
input  files  to  expand  the  scope  of  the  SMOFN,  but  if  necessary,  the  execution  logic  can  be 
enhanced  by  incoiporating  new  operational  rules  that  the  analysts  become  aware  of  through  the 
modelling  process.  The  resulting  threads  can  then  be  used  to  articulate  the  C2  processes  as  refined 
SOPs  and  the  model  is  available  for  further  analysis  and  improvement. 

A  major  discussion  item  that  came  out  of  one  of  the  SMOFN  development  workshops  was  the 
need  to  see  how  the  SOP  modelling  process  actually  works.  The  consensus  was  that  it  would  be 
easier  to  understand  if  one  or  two  examples  could  be  modelled  during  the  workshop.  The 
workshop  participants  selected  two  candidates  of  important  C2  practices;  one  had  no  organized 
SOP  while  the  other  SOP  was  considered  to  be  the  most  complex  one  that  had  been  documented. 
The  thought  was  that  if  these  two  cases  could  be  successfully  modelled  it  would  provide  ample 
evidence  as  to  the  viability  of  the  modelling  approach. 

In  each  case  the  approach  taken  was  to  capture  information  about  the  job  thread  within  CORE  (a 
software  package  designed  for  system  engineering  and  also  used  for  process  modelling)  and  then 
read  through  the  output  transcripts  with  the  operator  Subject  Matter  Expert  (SME)  to  make  sure 
the  model  executed  as  intended. 

Results:  The  SMOFN  has  achieved  its  goal  of  extending  the  detailed  OPCEN  SM  model  logic 
across  multiple  nodes,  each  with  their  own  jobs  and  resources  but  also  with  the  ability  to  share 
information.  This  information  sharing  takes  place  through  the  Net  Centric  virtual  Repository, 


IV 


DRDC  CORA  TR  2009-012 


whose  operational  logic  successfully  controls  the  interaction  of  information  between  operator 
perspectives  (i.e.  producer,  consumer  and  discovery)  as  well  as  between  different  OPCENs  within 
the  SMOFN. 


Typical  simulations  are  limited  in  scope  by  only  being  able  to  model  what  is  built  directly  into 
them.  On  the  other  hand,  SMOFN  reads  scenario  information  from  data  files  each  time  the 
simulation  is  started.  This  allows  a  single  version  of  the  model  to  be  used  across  a  limitless 
variety  of  scenarios.  It  also  allows  any  details  of  the  SMOFN  engine  to  remain  unclassified,  even 
though  the  files  that  it  uses  at  input  may  contain  classified  data. 

Both  SOP  modelling  trial  cases  successfully  demonstrated  how  to  quickly  (a  few  days  or  weeks 
from  start  to  finish)  build  and  validate  detailed  models  with  operator  SMEs.  The  results  were 
much  better  articulated  C2  processes  than  existed  before  and  they  provided  a  means  to  test  a 
broad  range  of  process  options.  The  added  bonus  was  that  formatted  United  States  Department  of 
Defense  Architecture  Framework  (DoDAF)  or  Canadian  Department  of  National  Defence  / 
Canadian  Forces  Architecture  Framework  (DNDAF)  product  documents  could  be  automatically 
generated  for  whatever  data  was  entered  into  the  model.  This  gives  the  SMEs  something  to  take 
back  as  a  documented  SOP. 

Future  plans:  The  process  of  gathering  data  for  process  threads  is  both  quick  and  effective;  the 
major  limitation  noted  so  far  is  the  availability  of  SMEs  to  provide  the  operational  context.  This  is 
expected  to  continue  to  be  the  biggest  implementation  hurdle  to  building  a  faithful  simulation  and 
executable  Canadian  Forces  (CF)  Command  Structure  operational  architecture.  What  could 
convince  operators  to  make  this  time  investment  is  the  fact  that  the  SME  interaction  produces 
immediate  results  in  the  form  of  DoDAF/DNDAF-compatible  products  that  can  be  used  by  the 
SMEs’  home  organizations  as  the  basis  for  writing  proper  SOPs.  There  are  several  SOPs  that 
have  been  suggested  as  future  candidates  to  be  included  in  the  SMOFN,  on  the  grounds  that  the 
SMEs  believed  those  processes  could  be  improved  if  they  were  properly  articulated  and 
documented.  These  would  be  given  the  same  treatment  as  the  trial  cases  modelled  here. 

The  final  step  in  the  modelling  will  involve  converting  the  C2  process  threads  to  SMOFN  data 
input  file  format.  A  portion  of  this  has  already  been  demonstrated  using  the  above  trial  cases  by 
decomposing  the  threads  into  simple  sub-jobs  and  then  linking  them  together. 

Significance:  The  SMOFN  engine  is  a  viable  simulation  of  OPCEN  operations  and  interactions. 
Although  a  large  amount  of  data  will  be  required  to  make  the  model  reflective  of  real  processes, 
the  authors’  recommendation  is  that  the  SMOFN  be  used  as  a  testbed  for  potential  changes  to 
operational  procedures.  To  make  the  simulation  and  its  results  as  realistic  as  possible,  it  is  also 
recommended  that  the  necessary  SME  hours  be  made  available  such  that  the  full  CF  Command 
Structure  could  be  modelled  to  some  degree  of  fidelity.  This  investment  of  time  would  make 
SMOFN  a  valuable  tool  in  studying  how  the  CF  does,  and  potentially  could,  operate. 
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Contexte  :  L’Equipe  de  recherche  operationnelle  interarmees  (ERO  (IA)  du  Centre  d’analyse  et 
de  recherche  operationnelle  (CARO)  de  Recherche  et  developpement  pour  la  defense  Canada 
(RDDC)  a  deploye  de  multiples  efforts  pour  modeliser  les  processus  relies  au  champ 
professionnel  Commandement,  controle,  communications,  informatique,  information, 
surveillance  et  reconnaissance  (C4ISR).  Dans  le  cadre  de  ces  travaux,  il  est  devenu  evident  que  la 
capacite  d’interrompre  des  taches  au  profit  d’autres  taches,  celles-la  plus  prioritaires,  allait  poser 
un  defi  unique  puisque  cette  capacite  etait  impossible  a  modeliser  au  moyen  des  graphiques 
d’activites  ordonnees  classiques.  La  solution  retenue  a  ete  de  creer  un  modele  pour  un  centre 
d’operations  (CENOP),  conformement  a  l’approche  d’une  machine  a  etats  qui  est  defmie  comme 
[4]  etant  «  un  appareil  permettant  de  stocker  l’etat  d’une  chose  a  un  moment  donne  et  pouvant 
agir  sur  les  entrees  afm  de  modifier  l’etat  et/ou  declencher  une  action  ou  la  production  d’une 
sortie  pour  un  changement  donne  ».  Cela  a  mene  au  developpement  de  la  machine  a  etats  pour  les 
CENOP  qui  est  decrite  aux  points  [5]  a  [8]. 

Le  moteur  de  la  machine  a  etats  de  nceuds  federes  comporte  toutes  les  fonctionnalites  de  la 
machine  a  etats  pour  les  CENOP,  en  plus  d’englober  les  interactions  entre  plusieurs  CENOP 
explodes  collectivement  par  le  biais  d’une  architecture  reseaucentrique.  II  permet  egalement  de 
simuler  tous  les  aspects  du  travail  d’un  CENOP  au-dela  de  la  simple  creation  de  produits.  Ce 
sont  ces  elements  ajoutes  qui  constituent  la  base  de  ce  rapport. 

Developpement  du  moteur  de  la  machine  a  etats  de  nceuds  federes  :  La  machine  a  etats  pour 
les  CENOP  a  ete  elargie  de  maniere  a  ce  que  les  interactions  reseaucentriques  entre  plusieurs 
CENOP  soient  prises  en  compte.  Essentiellement,  la  machine  a  etats  pour  les  CENOP  permettait 
de  tenir  compte  du  travail  execute  par  un  seul  CENOP  et  de  generer  ainsi  plusieurs  produits, 
d’apres  des  analyses  de  donnees.  Dans  la  machine  a  etats  de  nceuds  federes,  ce  genre  de  taches  de 
production  fait  non  seulement  l’objet  d’un  suivi  dans  plusieurs  CENOP,  mais  tous  les  produits 
que  ces  centres  creent  sont  aussi  televerses  dans  un  depot  en  reseau  commun  afm  qu’ils  puissent 
etre  accessibles  et  utilisables  par  tous  les  CENOP.  Avec  le  moteur  de  la  machine  a  etats  de  nceuds 
federes,  on  tente  de  representer  la  logique  essentielle  regissant  la  fag  on  dont  le  travail  est 
accompli  partout,  mais  en  insistant  particulierement  sur  la  necessite  de  s’ assurer  que  ce  moteur 
pourra  s’appliquer  integralement  aux  activites  integrees  entre  les  CENOP  en  reseau. 

Etant  donne  que  la  machine  a  etats  pour  les  CENOP  privilegiait  la  production  de  travail,  la 
plupart  des  activites  de  developpement  de  la  machine  a  etats  de  nceuds  federes  ont  surtout 
consiste  a  ajouter  l’effet  des  nceuds  a  l’exterieur  du  Producteur  de  meme  qu’a  creer  les  interfaces 
entre  tous  les  nceuds.  Producteur  y  compris,  il  y  a  cinq  nceuds,  ou  types  d’activites,  de  representes 
dans  la  machine  a  etats  de  nceuds  federes,  et  chacun  de  ces  nceuds  comporte  un  ensemble 
d’activites  uniques  dont  il  est  responsable. 
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6.  Le  Producteur  genere  des  produits  a  partir  des  entrees  de  donnees  disponibles. 

7.  Le  Consommateur  regoit  les  produits  dont  il  se  sert  pour  le  maintien  de  la  connaissance  de  la 
situation  (CS).  II  peut  generer  des  questions  et  les  envoyer  a  l’activite  Decouverte. 

8.  Decouverte  regoit  les  questions  du  Consommateur  et  cherche  pour  determiner  s’il  est 
possible  d’y  repondre  a  partir  de  l’information  disponible.  L’information  decouverte  est 
transmise  au  Producteur  et  celle  qui  manque  est  demandee  a  des  Sources  de  l’exterieur. 

9.  Les  Sources  de  l’exterieur  regoivent  les  demandes  d’ information  et  envoient  les  donnees 
manquantes  au  Producteur. 

10.  Le  Depot  enregistre  1’ information  et  permet  aux  autres  nceuds  de  communiquer. 

Alimentation  du  moteur  de  la  machine  a  etats  de  nceuds  federes  (SMOFN)  :  Le  principal 
avantage  de  cette  machine  a  etats  reside  dans  le  fait  que  le  modele  a  proprement  parler  se  rapporte 
uniquement  a  l’execution  de  la  logique.  Tous  les  parametres  d’ exploitation,  tels  que  le  nombre 
d’operateurs  dans  un  CENOP  et  leurs  competences,  ou  le  nombre  de  taches  a  accomplir,  sont 
extraits  de  fichiers  de  donnees  a  l’etape  de  la  configuration  de  la  simulation.  Ces  donnees  doivent 
etre  representatives  des  parametres  d’ exploitation  des  CENOP  modelises,  l’objectif  etant  de 
simuler  avec  exactitude  le  flux  de  donnees  entre  ces  demiers.  L’accent  est  mis  en  particulier  sur  la 
description  des  fils  de  taches  dans  lesquels  interviennent  de  multiples  CENOP,  comme  le 
processus  servant  a  signaler  les  evenements  dans  un  theatre  d’ operations  et  a  y  reagir,  ou  la 
preparation  de  comptes  rendus  generaux  quotidiens.  Une  autre  composante  importante  est  la 
composition  des  divers  CENOP,  en  ce  qui  conceme  le  nombre  d’operateurs  pour  un  poste  en 
particulier  ainsi  que  les  competences  pour  lesquelles  ils  ont  ete  formes.  Malgre  le  fait  que  la 
majorite  de  ces  donnees  sera  classifiee,  le  moteur  de  la  machine  a  etats  de  nceuds  federes,  lui, 
demeurera  non  classifie  etant  donne  qu’il  sera  enregistre  dans  un  fichier  different  de  celui  qui 
renfermera  les  donnees  qu’il  lira  lorsqu’il  sera  execute. 

Les  analystes  commencent  par  convertir,  en  un  modele,  les  elements  d’ information  disponibles 
(en  general,  de  la  documentation  ou  des  descriptions  verbales  faites  par  les  operateurs)  sur  les 
pratiques  relatives  au  commandement  et  au  controle  (C2).  En  theorie,  ces  pratiques  devraient  etre 
sous  forme  d’ Instructions  permanentes  d'operation  (IPO)  s’executant  comme  un  fil  du  debut  a  la 
fin.  Or,  la  verite  est  que  la  plupart  des  IPO  sont  generalement  incompletes  ou  inexactes,  de  sorte 
que,  dans  les  faits,  leur  deroulement  logique  differe  de  la  description  qui  en  est  faite.  Les 
connaissances  acquises  dans  le  cadre  des  travaux  anterieurs  portant  sur  le  moteur  de  la  machine  a 
etats  de  nceuds  federes  servent  a  combler  ces  ecarts  de  fag  on  a  faire  en  sorte  que  le  processus  de 
modelisation  finisse  par  representer  des  fils  entierement  executables.  Les  fils  peuvent  non 
seulement  etre  recrees  comme  des  fichiers  d’entree  pour  elargir  la  portee  de  la  machine  a  etats  de 
nceuds  federes,  mais,  s’il  y  a  lieu,  la  logique  d’execution  peut  etre  amelioree  par  l’ajout  de 
nouvelles  regies  operationnelles  que  les  analystes  decouvrent  par  le  biais  du  processus  de 
modelisation.  Les  fils  ainsi  obtenus  peuvent  ensuite  etre  utilises  pour  organiser  les  processus  C2 
puisqu’il  existe  des  IPO  bien  elaborees  et  un  modele  permettant  de  faire  d’ autres  analyses  et 
ameliorations. 

II  est  ressorti  d’un  des  ateliers  sur  le  developpement  d’une  machine  a  etats  de  nceuds  federes  une 
question  importante  et  c’est  la  necessite  de  voir  comment  le  processus  de  modelisation  des  IPO 
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fonctionne  vraiment.  II  y  avait  unanimite  que  ce  processus  serait  plus  facile  a  comprendre  s’il 
etait  possible  de  presenter  un  ou  deux  modeles  durant  l’atelier.  Les  participants  de  cet  atelier  ont 
selectionne  deux  cas  representatifs  de  pratiques  C2  importantes  :  dans  le  premier  cas,  il  n’y  avait 
pas  d’lPO  structuree  et,  dans  le  second,  1’IPO  etait  consideree  comme  etant  l’une  des  plus 
complexes  qui  aient  ete  documentees.  De  l’avis  general,  la  modelisation  de  ces  deux  cas,  si  elle 
etait  reussie,  permettrait  de  prouver  amplement  la  viabilite  de  Papproche  de  modelisation. 

Pour  chacun  des  deux  cas,  Papproche  retenue  a  consiste  a  representer  Pinformation  sur  le  fil  des 
taches  dans  le  logiciel  CORE  (un  logiciel  congu  pour  la  systemique  et  aussi  utilise  pour  la 
modelisation  des  processus),  puis  a  lire  les  transcriptions  obtenues  avec  P expert  en  matiere 
d’operateurs  (EEM)  afm  de  s’assurer  que  le  modele  s’executait  comme  prevu. 

Resultats  :  La  machine  a  etats  de  nceuds  federes  a  permis  d’atteindre  le  but  qui  etait  d’etendre  la 
logique  detaillee  du  modele  de  la  machine  a  etats  pour  les  CENOP  a  des  nceuds  multiples,  chaque 
nceud  ay  ant  ses  propres  taches  et  ressources,  tout  en  permettant  le  partage  de  Pinformation.  Ce 
partage  de  Pinformation  est  rendu  possible  grace  au  depot  reseaucentrique  virtuel  dont  la  logique 
operationnelle  permet  de  controler  efficacement  Pinteraction  de  Pinformation  entre  les 
perspectives  des  operateurs  (c.-a-d.  le  Producteur,  le  Consommateur  et  Pactivite  Decouverte)  de 
meme  qu’entre  les  differents  CENOP  dans  la  machine  a  etats  de  nceuds  federes. 

Les  simulations  typiques  ont  une  portee  limitee,  car  elles  ne  permettent  que  de  modeliser  ce  qui  y 
est  integre  directement.  Par  ailleurs,  la  machine  a  etats  de  nceuds  federes  extrait  Pinformation  des 
scenarios  contenus  des  fichiers  de  donnees  chaque  fois  que  la  simulation  est  lancee,  ce  qui  permet 
d’utiliser  une  seule  version  du  modele  pour  un  eventail  infini  de  scenarios  et  de  faire  en  sorte  que 
tous  les  details  du  moteur  de  la  machine  a  etats  de  nceuds  federes  restent  non  classifies  meme  si 
les  fichiers  auxquels  ce  moteur  a  recours  renferment  des  donnees  classifiees. 

Les  deux  cas  de  modelisation  des  IPO  testes  ont  permis  de  demontrer  avec  succes  comment  creer 
et  valider  rapidement  (en  seulement  quelques  jours  ou  semaines,  du  debut  a  la  fin)  des  modeles 
detailles  avec  des  operateurs  experts  en  la  matiere.  Les  processus  C2  ainsi  obtenus  etaient 
beaucoup  plus  structures  que  ceux  qui  existaient  avant  et  ils  permettaient  de  tester  un  vaste 
eventail  de  processus  possibles,  En  plus,  il  etait  possible  de  generer  automatiquement  des 
documents  de  produits  dans  un  format  compatible  avec  le  United  States  Department  of  Defense 
Architecture  Framework  (DoDAF)  ou  le  cadre  d’ architecture  du  ministere  de  la  Defense  nationale 
et  des  Forces  canadiennes  (DNDAF)  pour  toutes  les  donnees  incorporees  dans  le  modele,  des 
documents  que  les  EEM  pouvaient  soumettre  comme  IPO  documentees. 

Plans  futurs  :  Le  processus  de  collecte  des  donnees  pour  les  fils  des  processus  est  a  la  fois  rapide 
et  efficace;  la  principale  limite  observee  a  ce  jour  est  le  fait  qu’il  n’y  a  pas  d’EEM  de  disponibles 
pour  foumir  le  contexte  operationnel.  Sur  le  plan  de  la  mise  en  ceuvre,  cela  devrait  continuer 
d’etre  le  plus  gros  obstacle  au  developpement  d’une  architecture  operationnelle  simulee  et 
executable  qui  soit  fidele  pour  la  structure  de  commandement  des  Forces  canadiennes  (FC).  Ce 
qui  pourrait  convaincre  les  operateurs  de  faire  cet  investissement  en  temps  est  le  fait  que 
Pinteraction  des  EEM  donne  des  resultats  immediats  sous  la  forme  de  produits  compatibles  avec 
les  DoDAF/DNDAF,  qui  peuvent  servir  de  base,  aux  organisations  d’ attache  de  ces  experts,  pour 
la  redaction  de  leurs  propres  IPO.  Les  EEM  ont  suggere  que  plusieurs  IPO  soient  incorporees 
dans  la  machine  a  etats  de  nceuds  federes  parce  qu’ils  croient  que  ces  processus  pourraient  etre 
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ameliores  s’ils  etaient  bien  structures  et  documentes.  Ces  IPO  feraient  l’objet  du  meme  traitement 
que  les  cas  d’essai  modelises  dont  il  est  ici  question. 

L’etape  finale  de  la  modelisation  consistera  a  convertir  les  fils  de  processus  C2  dans  un  format  de 
fichier  d’entree  de  donnees  pour  la  machine  a  etats  de  nceuds  federes.  On  a  deja  fait  la 
demonstration  d’une  partie  de  cette  etape  dans  le  cadre  de  la  modelisation  des  cas  d’essai 
susmentionnes,  en  decomposant  les  fils  en  sous-taches  simples,  puis  en  les  liant  entre  elles. 

Portee  :  Le  moteur  de  la  machine  a  etats  de  nceuds  federes  est  une  simulation  viable  des 
operations  des  CENOP  et  de  leurs  interactions.  Malgre  le  fait  qu’il  faudra  une  grande  quantite  de 
donnees  pour  faire  en  sorte  que  le  modele  reflete  les  processus  veritables,  les  auteurs 
recommandent  que  la  machine  a  etats  de  nouds  federes  servent  de  banc  d’essai  pour  tester  des 
changements  eventuels  dans  les  procedures  operationnelles.  Pour  rendre  la  simulation  et  ses 
resultats  le  plus  realistes  possible,  on  recommande  aussi  que  les  heures-personnes  EEM 
necessaires  soient  accordees  pour  permettre  la  modelisation  assez  fidele  de  toute  la  structure  de 
commandement  des  Forces  canadiennes.  Le  temps  qui  serait  ainsi  investi  par  ces  EEM  permettrait 
de  faire  de  la  machine  a  etats  de  nceuds  federes  un  outil  tres  utile  pour  etudier  comment  les  FC 
fonctionnent  a  l’heure  actuelle  et  comment  elles  pourraient  eventuellement  fonctionner. 
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1  Introduction 


The  State  Machine  of  Federated  Nodes1  (SMOFN)  has  been  created  as  an  engine  to  drive 
simulations  of  work  performed  by  people  who  are  able  to  share  information  over  a  common 
network.  We  refer  to  it  as  an  “engine”  because  it  contains  the  logic  to  handle  the  modelled 
concepts  in  a  generic  sense,  while  the  specific  details  of  the  simulation  are  read  upon  execution. 
In  this  sense,  the  SMOFN  becomes  a  “model”  when  it’s  inherent  coding  and  the  necessary  data 
files  are  considered  together.  Its  generic  logic  allows  any  number  of  specific  real  world  scenarios, 
either  current  or  potential,  to  be  studied  by  tailoring  the  input  data  to  each  situation.  While  the 
SMOFN  logical  rules  are  generic  enough  to  allow  for  various  types  of  work,  they  were  inspired 
by  data  analysis  tasks  performed  at  an  operations  centre  (OPCEN2)  for  the  purpose  of  providing 
information  to  the  OPCEN  commander,  or  to  other  OPCENs.  The  SMOFN  expands  on  previous 
work,  described  below,  by  allowing  for  collaboration  between  multiple  nodes  interacting  over  a 
shared  network.  It  also  adds  the  concept  of  follow-up  work,  such  as  asking  questions  and 
requesting  new  data,  based  on  what  has  already  been  completed. 

1.1  Background 

In  2003,  the  Defence  Research  and  Development  Canada  (DRDC)  Collaborative  Capability 
Definition,  Engineering  and  Management  (CapDEM)  Technology  Demonstration  (TD)  project 
began  development  of  system  engineering  processes  that  were  organized  around  and  leveraged 
the  United  States  Department  of  Defense  Architecture  Framework  (DoDAF)  [2].  To  study  and 
evaluate  these  processes,  CapDEM  required  an  organization  or  system  to  form  the  basis  of  an 
executable  architecture  model  (an  operational  and/or  system  architecture  model  that  can  be  run, 
or  executed,  as  a  simulation  in  order  to  validate  the  modelled  logic  or  study  the  emerging 
behaviour),  as  well  as  a  software  package  to  capture  the  data  in  and  aid  in  the  analysis.  The  Joint 
Intelligence  and  Information  Fusion  Capability  (JIIFC)  project  was  chosen  as  a  convenient  use- 
case  and  CORE,  by  Vitech  Corporation,  was  chosen  as  the  software  application. 

Meanwhile,  the  DRDC  Centre  for  Operational  Research  and  Analysis  (CORA)  Joint  Studies 
Operational  Research  Team  (JSORT)  had  been  assigned  the  responsibility  of  providing  analysis 
support  to  JIIFC  and  was  looking  for  appropriate  modelling  and  simulation  (M&S)  methods  and 
tools  to  support  that  activity.  CapDEM  and  JSORT  agreed  that  long-term  research  collaboration 
would  help  to  improve  the  Department’s  ability  to  model  complex  command  and  control  (C2) 
architectures. 

Another  of  JSORT’s  research  thrusts  was  in  direct  support  of  the  Canadian  Forces  (CF) 
Command,  Control,  Computers,  Communications,  Intelligence,  Surveillance  and  Reconnaissance 
(C4ISR)  Campaign  Plan  (CP)  [3].  This  effort  included  the  development  of  an  analytical  basis  to 

1  The  term  “node”  is  used  as  an  abstraction  of  the  different  roles  performed  by  an  OPCEN  (Producer, 
Consumer,  etc.),  of  the  OPCENs  themselves,  or  of  the  different  roles  within  the  chain  of  command.  These 
are  “federated”  in  the  sense  that  they  are  operating  as  one  large  interconnected  entity  -  their  relationship  is 
the  operational  equivalent  of  a  federated  database  [1]. 

2  Although  the  modelling  was  based  on  an  “operations”  centre,  and  the  term  OPCEN  is  used  throughout 
this  paper,  the  resulting  logic  applies  equally  to  any  type  of  command  or  support  centre  that  performs 
identifiable  tasks. 
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allow  capability-engineering  staff  to  build  and  assess  executable  Net-Centric  architectures  (i.e., 
executable  architectures  that  are  based  upon,  and  take  advantage  of,  a  networked  environment). 
The  objective  was  to  define  requirements  for  future  capabilities  and  make  measurable  investment 
decisions  by  helping  operators  to  build  realistic  C2  architectures  that  capability  engineers  can  use 
to  compare  current  and  planned  options. 

During  several  modelling  efforts,  it  became  apparent  that  the  ability  to  interrupt  jobs  in  favour  of 
higher  priorities  created  a  unique  challenge  because  it  could  not  be  modelled  using  classical 
sequenced  activity  diagrams.  This  was  a  significant  concern  because  the  ability  to  interrupt  jobs  is 
an  important  difference  between  the  current  job  processing  paradigm  -  Task,  Post,  Process,  Use 
(TPPU)  -  and  its  predecessor  Task,  Process,  Exploit,  Disseminate  (TPED).  The  chosen  solution 
was  to  create  a  model  of  an  OPCEN  using  the  approach  of  a  state  machine  (SM),  which  is  defined 
in  [4]  as  “any  device  that  stores  the  status  of  something  at  a  given  time  and  can  operate  on  input 
to  change  the  status  and/or  cause  an  action  or  output  to  take  place  for  any  given  change.”  This  led 
to  the  development  of  the  OPCEN  SM  described  in  [5]  through  [8],  This  was  a  leap  forward  in 
process  modelling,  especially  where  human  behaviour  and  decision  making  are  involved  because 
it  provides  a  structured  approach  to  explicitly  handle  contention  considerations  when  jobs  must  be 
interrupted  for  higher  priority  work  and  then  returned  to  later.  A  short  summary  of  that  work  is 
covered  in  the  next  two  sections. 


1.2  Primer  on  TPED  vs.  TPPU 

TPED  logic  implies  that  each  job  is  a  serial  process:  jobs  are  worked  on  from  start  to  finish 
without  being  interrupted.  Flowchart  diagrams  (ie.  those  in  CORE  and  similar  modelling 
packages)  can  simulate  TPED  by  putting  the  job  processes  in  a  loop  and  repeating  for  each  job. 
TPPU,  on  the  other  hand,  allows  jobs  to  be  interrupted  by  higher  priority  jobs.  As  illustrated  in 
Figure  1,  updates  of  jobs  processed  through  TPPU  are  posted  at  regular  intervals  and  the  utility  of 
the  job  increases  as  more  posts  are  made.  This  accrued  utility  is  saved  even  if  the  job  is 
interrupted.  TPPU  leads  to  concurrent  behaviour  (several  partially  processed  jobs  existing  at  the 
same  time)  that  is  too  complex  to  model  using  classical  flowchart  diagrams.  The  OPCEN  SM 
overcame  this  by  stopping  time  and  executing  the  logic  to  reassign  operators  to  jobs  in  order  of 
priority.  It  then  steps  forward  in  time  and  repeats  the  process.  Progress  within  each  job  is  tracked 
by  recording  the  job’s  state  and  updating  it  at  each  time  step. 
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Figure  1:  Task,  Post,  Process,  Use  (TPPU) 


1 .3  Overview  of  OPCEN  SM  Model 

The  OPCEN  SM  logic  flow  is  illustrated  in  Figure  2.  The  actual  simulation  is  contained  inside  the 
red  box,  whereas  the  rest  of  the  diagram  represents  activities  performed  to  control  the  input  to  and 
output  from  the  simulation.  Examining  the  diagram  from  left  to  right,  the  following  activities  are 
executed: 

1.  Setup  reads  data  from  input  files  and  saves  the  data  to  variables  stored  in  memory  to  be 
accessed  by  the  simulation; 

2.  The  simulation  enters  a  Loop  (LP)  which  will  be  executed  for  every  time  step.  This  loop 
includes  steps  3  through  7  below; 

3.  Run-to-End-Check  reads  the  clock  variable  to  see  if  the  time  step  designated  as  the  end  of 
the  simulation  has  been  reached.  If  so,  the  loop  exits,  otherwise  the  simulation  enters  the  red 
box; 

4.  Clock  increments  the  clock  variable  by  one  time  step  and  sends  the  signal  to  the  bottom 
branch  indicating  that  it  can  now  execute; 

5.  Schedule  Processing  receives  that  signal  and  reads  the  variables  from  the  input  data  to  see  if 
any  jobs  are  scheduled  to  begin  during  this  time  step.  If  so,  those  jobs  are  added  to  the  events 
list; 
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6.  Thread  &  Queue  Processing  performs  the  actual  simulation  of  activity  that  occurs  during 
the  current  time  step.  The  details  of  how  this  is  accomplished  are  handled  at  a  lower  level  of 
decomposition; 

7.  End-of-Cycle  Reporting  saves  to  output  variables  any  data  that  needs  to  be  accessed  by  later 
time  steps  or  output  at  the  end  of  the  simulation; 

8.  Once  the  Run-to-End-Check  finds  that  the  simulation  has  reached  the  final  time  step  and  the 
Loop  finishes,  End-of-Run  Reporting  goes  through  the  data  that  has  been  saved  to  variables, 
and  outputs  that  data  as  a  series  of  spreadsheets. 

The  SMOFN  engine  includes  all  of  the  above  functionality  and  expands  on  it  to  account  for 
interactions  between  several  OPCENs  operating  collectively  through  a  Net-Centric  Architecture. 
It  also  adds  the  capability  to  simulate  all  aspects  of  OPCEN  work  beyond  simply  creating 
products,  such  as  posing  questions  based  on  newly  received  products,  and  searching  for  older 
products  to  fill  information  gaps.  These  expansions  form  the  basis  of  the  rest  of  this  report. 
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1.4  SMOFN  Contract  Summary 

DRDC  CORA  supported  the  development  of  the  SMOFN  engine  through  a  contract  for 
specialized  system  engineering  support.  This  allowed  JSORT  to  exploit  all  the  capabilities  of 
CORE  as  well  as  gain  access  to  Model-Based  Capability  Engineering  (MBCE)  expertise.  The 
project  was  originally  split  into  an  initial  exploratory  phase  and  four  (4)  optional  phases.  Each 
phase  and  version  of  the  model  yielded  new  insights  and  that  experience  was  used  to  scope  out 
the  requirements  and  development  path  of  the  subsequent  phase. 

Each  phase  was  composed  of  a  development  package  and  a  workshop  (except  phase  2  which  had 
two  workshops).  The  workshops  provided  a  forum  to  get  operator  and  researcher  feedback  about 
the  validity  of  the  model  proposed  at  that  stage  and  to  develop  the  requirements  for  the 
subsequent  phase.  The  deliverables  from  the  contractor  were  based  on  periodic  delivery  of 
updated  source  code  and  a  revised  user  manual  at  the  end  of  each  phase.  The  latest  version  of  the 
user  manual  can  be  found  at  Annex  A.  A  summary  of  the  dates  each  phase  was  active  and  what 
was  accomplished  follows: 

1.  Phase  1  -  (January  2006  to  March  2006).  The  first  phase  was  an  exploratory  effort  which 
used  nominal  data  to  put  together  a  simple  generic  version  of  the  SMOFN  engine.  The 
conclusion  was  that  the  SMOFN  was  a  feasible  concept  and  the  requirements  capture  process 
began  for  a  full-scale  version  of  the  SMOFN; 

2.  Phase  2  -  (May  2006  to  September  2006).  This  was  the  major  development  phase  to  build 
the  generic  data  file  and  thread  structure  needed  to  support  a  fully  flexible  SMOFN  engine. 
This  phase  also  included  the  articulation  of  the  basic  underlying  conceptual  framework  that 
allows  the  model  to  be  instantiated  as  a  completely  scale  free  design. 

3.  Phase  3  -  (October  2006  to  January  2006).  This  phase  involved  continued  testing,  validation 
and  extension  of  the  SMOFN  engine  to  handle  Consume,  Discover,  External  Sources  and 
Repository; 

4.  Phase  4  -  (February  2006  to  March  2007).  Implementation  of  the  Discover  and  Repository 
nodes  was  completed.  A  process  of  rapid  Standard  Operating  Procedure  (SOP)  modelling  was 
also  developed  and  tested  to  improve  the  usability  of  the  SMOFN,  as  modelled  job  threads 
could  be  quickly  documented  and  validated;  and 

5.  Phase  5  -Not  activated.  The  workshop  assigned  to  this  phase  was  used  to  augment  phase  2. 

The  contract  was  successfully  completed  within  the  total  costs  and  schedule  laid  out  in  the  initial 
statement  of  work.  The  results  of  the  contract  (and  the  basis  of  this  report)  have  been  presented  at 
two  international  conferences  [9],  [10]. 

1.5  Aim 

This  report  is  intended  to  document  the  functionality  of  the  SMOFN  simulation.  If  the  investment 
of  time  is  to  be  made  to  collect  the  data  necessary  to  turn  the  SMOFN  into  a  full  simulation  of  the 
CF  command  structure,  it  is  important  to  generate  an  understanding  of  how  SMOFN  works  and 
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therefore  of  what  data  would  be  required.  With  that  in  mind,  a  secondary  aim  is  to  document  the 
proposed  data  collection  method,  drawing  from  one  example  of  an  undocumented  SOP,  and  one 
example  of  an  extensively  documented  SOP. 


1.6  Scope  of  the  Modelling  Effort 

The  focus  of  the  SMOFN  engine  is  on  operator  workload  during  product  creation.  Nodes  other 
than  the  Producer  are  only  modelled  insofar  as  necessary  to  control  data  flow.  Also,  although  the 
model  accounts  for  how  much  time  is  spent  on  each  step  of  a  product  creation  job,  it  is  not 
concerned  with  the  details  about  how  each  step  is  performed.  While  the  concept  recognizes  that 
Consumer  OPCENs  use  received  products  to  inform  their  decisions  as  to  what  actions  are  to  be 
taken,  this  C2  activity  is  not  directly  accounted  for  in  the  SMOFN. 

While  the  architecture  views  presented  in  this  report  were  created  when  DoDAF  was  the  standard 
framework  used  by  the  CF,  they  are  all  compatible  with  the  equivalent  views  in  the  Canadian 
Department  of  National  Defence  (DND)/CF  Architecture  Framework  (DNDAF)  [11], 

1 .7  Layout  of  Report 

This  introductory  chapter  is  intended  to  present  SMOFN’ s  predecessor,  the  OPCEN  SM,  and  to 
describe  the  way  forward  from  the  OPCEN  SM  to  SMOFN.  The  rest  of  the  report  is  split  into  2 
parts.  Part  1  describes  the  development  effort  to  create  the  SMOFN  and  Part  2  examines  the  way 
forward  to  populate  and  run  the  SMOFN  as  a  simulation  of  the  CF  Command  Structure. 

Part  1  begins  in  Chapter  2  with  a  description  of  the  conceptual  framework  that  the  SMOFN  is 
intended  to  simulate,  including  a  walkthrough  of  the  modelled  logic  as  it  applies  to  each  node. 
Chapter  3  then  describes  the  SMOFN  engine  itself,  as  it  is  implemented  in  CORE.  Chapter  4 
describes  the  data  files  that  the  SMOFN  refers  to  in  order  to  define  the  jobs  and  OPCENs  that  are 
to  be  simulated.  This  read-on-execution  input  is  what  allows  the  SMOFN  to  be  flexible  and  scale- 
free. 

Part  2  then  begins  with  Chapter  5,  which  explains  how  data  can  be  collected  so  the  data  files 
described  in  Chapter  4  can  be  tailored  to  reflect  reality.  Chapter  6  outlines  two  examples  of  the 
data  collection  process  that  were  used  as  trial  cases.  Finally,  Chapter  7  sums  up  with  the 
conclusions  and  recommendations  stemming  from  this  paper. 
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Part  1  -  Developing  the  SMOFN  Engine 
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2  SMOFN  Engine  Modelling  Concepts 


2.1  Extension  Beyond  the  OPCEN  SM 

The  OPCEN  SM  has  been  extended  to  account  for  Net-Enabled  interactions  between  several 
OPCENs.  In  essence,  the  OPCEN  SM  accounted  for  the  work  done  by  a  single  OPCEN  to 
produce  several  products  based  on  data  analysis.  In  the  SMOFN,  not  only  are  such  production 
jobs  tracked  within  several  OPCENs,  but  the  products  they  create  are  uploaded  to  a  common, 
networked  Repository  so  that  all  products  can  be  accessed  and  used  by  any  OPCEN.  The  SMOFN 
engine  is  an  attempt  to  capture  the  essential  logic  that  governs  the  way  work  is  conducted  in  a 
general  sense,  but  with  particular  emphasis  on  ensuring  that  it  can  be  fully  applied  to  integrated 
activity  between  networked  OPCENs. 

Because  the  OPCEN  SM  concentrated  on  job  production  by  an  OPCEN,  there  was  not  much  that 
needed  to  be  added  there.  Instead,  most  of  the  work  concentrated  on  adding  the  effect  of  nodes 
outside  of  the  Producer,  as  well  as  creating  the  interactions  between  all  of  the  nodes.  Within  the 
Producer  node,  the  only  modification  has  been  to  allow  users  to  create  customized  job  threads. 
The  OPCEN  SM  had  assumed  that  every  job  involved  a  maximum  of  10  steps,  with  fewer  steps 
handled  by  assigning  zero  time  to  unneeded  steps.  Instead,  SMOFN  builds  its  job  threads 
dynamically  by  assigning  each  step  a  unique  name  and  linking  any  number  of  them  together  by 
referencing  the  names  of  subsequent  steps  until  it  reaches  a  final  step  called  “COMPLETE”. 

2.2  Conceptual  OV-1 

Figure  3  illustrates  the  concept  of  SMOFN  as  a  high-level  operational  concept  graphic,  known  in 
DoDAF  and  DNDAF  as  an  Operational  View  (OV)-l.  It  is  a  scale-free  design  in  the  sense  that  it 
is  equally  valid  for  representing  interactions  between  nodes,  or  within  a  node,  or  even  within  a 
single  operator’s  perspectives  (depending  on  their  assigned  functions).  For  example,  every 
operator  in  every  OPCEN  performs  the  Consumer,  Producer,  and  Discovery  activities  at  one  time 
or  another.  The  major  difference  between  instantiations  of  each  activity  in  a  node  is  that  the 
processes  become  more  formal  as  the  number  of  individuals  involved  or  span  of  control  increases. 

The  dashed  lines  show  the  net  transfer  of  Products,  Questions,  Queries,  Results,  and  Responses, 
while  the  solid  lines  are  a  reminder  that  all  of  the  transactions  actually  occur  through  the 
Repository,  the  interface  to  which  is  implemented  by  some  form  of  Portal.  This  conceptual  OV-1 
diagram  was  used  as  the  basis  for  describing  the  logic  that  controls  the  interactions  between  the 
various  nodes  in  the  SMOFN.  More  specifically,  it  was  used  to  define  the  interactions  between 
each  node  and  the  Repository. 

This  OV-1  drew  inspiration  from  the  information  collection  and  processing  sequence  as 
illustrated  in  Figure  25  of  [12]  and  uses  feedback  received  from  Maritime  Forces  Atlantic 
(MARLANT)  Operations  Research  (N02OR),  who  have  developed  it  further  to  suit  the  specific 
purposes  of  Marine  Security  Operations  Centre  (MSOC)  East  [13]. 
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i  Action  I 


Figure  3:  Scale-free  SMOFN  Operational  Concept  Graphic  OV-1 

Each  of  the  nodes  illustrated  in  Figure  3  has  a  unique  responsibility: 

1.  The  Produce  activity  generates  products  from  available  data  inputs.  The  data  is  drawn  from 
the  Repository  and  may  have  been  put  there  either  as  the  results  of  the  Discover  process  or 
as  External  Sources’  responses  to  queries.  The  products  are  then  sent  back  to  the  Repository 
for  the  Consumer; 

2.  The  Consume  activity  receives  products  which  it  uses  to  maintain  situational  awareness  (SA) 
and  as  a  basis  for  commanding  action  to  be  taken.  If  the  Consumer  has  questions  based  on 
the  received  products,  it  sends  them  to  the  Discover  activity; 

3.  The  Discover  activity  receives  questions  from  the  Consumer  and  searches  to  see  if  they  can 
be  answered  using  available  information.  Any  discovered  information  is  passed  to  the 
Producer  to  incorporate  into  existing  or  new  products.  When  any  or  all  of  the  information 
cannot  be  found,  the  question  is  converted  into  a  formal  query  to  request  new  or  modified 
inputs  from  External  Sources; 

4.  The  External  Sources  activities  receive  queries  and  send  responses  to  the  Producer  in  the 
form  of  new  data;  and 

5.  The  Repository  stores  information  and  acts  as  a  medium  for  the  other  nodes  to  communicate. 
The  Repository  node  contains  all  the  information  created  or  used  by  the  other  nodes  and  uses 
its  operational  rules  to  handle  the  connectivity  between  them. 
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2.3  Examples  of  the  Process 

Table  1:  Examples  of  the  Process 


Node 

Generic  Example 

MSOC  Example 

Producer 

Assume  that  Operator  #1  (Op  #1)  takes  on 
the  role  of  a  producer  who  follows  a  series 
of  steps  when  preparing  a  report.  The  report 
is  sent  to  the  Repository  as  a  product  to  be 
consumed  by  Operator  #2  (Op  #2). 

MSOC  data  analysis  produces  a  report  that 
includes  the  location  of  a  vessel  of  interest 
(VOI)  in  a  large  area  of  the  ocean.  The 
producer  updates  the  position  intelligence  on 
likely  intent  and  time  frame  in  the 
repository. 

Consumer 

Op  #2  uses  the  report  as  a  basis  for  their 
actions.  If  the  report  does  not  contain 
sufficient  information  or  is  incorrect  from 
Op  #2’s  perspective,  a  request  can  be  made 
for  more  information.  This  request  can  be 
sent  back  to  Op  #1,  handled  internally  by  Op 
#2,  or  sent  to  a  third  party. 

As  the  consumer,  Comd  MSOC  views  that 
information  via  the  portal  to  gain  situational 
awareness  about  the  VOI,  and  notices  that 
the  data  is  three  days  old. 

Discoverer 

Any  operator  that  looks  for  more 
information  now  takes  on  the  role  of 
discoverer.  If  the  information  is  found,  it  is 
forwarded  to  a  producer  (who  may  or  may 
not  be  the  original  producer  or  consumer) 
who  then  creates  the  new  product  with  the 
found  information  for  Op  #2. 

Discovery  is  initiated  to  see  what  newer  data 
is  available,  including  assets  that  are 
currently  monitoring  the  VOI.  None  are 
assigned  so  a  query  is  made  to  update  the 
VOI  position  using  external  sources. 

External 

Sources 

If  the  discovery  process  fails  to  yield  the 
correct  information,  then  a  formal  request 
for  help  is  sent  to  External  Sources.  The 
query  includes  direction  to  provide  a  single 
response  or  start  automatic  updates  of  the 
data.  As  with  information  found  by 
Discovery,  new  data  is  forwarded  to  a 
Producer. 

If  no  other  information  is  available,  then  an 
aircraft  is  assigned  to  search  for  the  VOI. 
The  aircraft  may,  or  may  not,  find  it  but 
either  way  the  results  of  the  search  mission 
are  posted  to  the  Repository. 

Producer 

The  Producer  incorporates  the  external 
response  and/or  Discovery  results  into  either 
a  new  or  existing  product  for  the  consumer 
(Op  #2).  If  the  query  involves  automatic 
updates  of  the  data  then  the  producer  will 
factor  that  data,  where  relevant,  into  any 
subsequent  products. 

As  the  Producer,  MSOC  data  analysis  uses 
those  results  in  future  analysis  products, 
always  with  a  view  toward  increasing  the 
Consumer’s  (Comd  MSOC)  SA. 

Table  1  describes  how  the  roles  illustrated  in  Figure  3  work  together.  The  first  example  describes 
the  logic  as  the  SMOFN  is  designed  in  a  generic  sense.  The  second  example  is  based  on  the 
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specific  case  of  an  MSOC  operation,  the  details  of  which  could  be  captured  in  the  SMOFN  data 
files.  This  is  meant  to  illustrate  how  the  SMOFN’ s  generic  coding  can  be  used  to  study  real-world 
scenarios. 

Note  that  in  the  generic  example,  the  only  relevant  factor  is  the  switching  of  roles  between 
producer,  consumer  and  discoverer  so  the  SMOFN  interpretation  is  equally  valid  for  actions  by  a 
single  person  or  separated  between  multiple  positions. 

2.4  Logic  Within  Each  Node 

So  far,  this  chapter  has  focused  on  describing  what  each  node  is  responsible  for,  and  how  it 
interacts  with  the  nodes  around  it.  This  section  will  provide  the  details  of  the  logic  that  must  be 
executed  by  each  node  in  order  to  accomplish  its  tasks. 

2.4.1  Producer  Logic 

The  focus  of  the  OPCEN  SM  was  the  logic  controlling  Producer  threads.  Because  the  SMOFN 
includes  multiple  OPCENs,  it  expands  on  this  functionality  by  including  a  check  for  the  arrival  of 
new  jobs  at  each  one.  Each  OPCEN  then  uses  the  OPCEN  SM  logic  rules  to  assign  operators  to 
jobs.  First,  each  job  is  examined  in  order  of  priority  and  assigned  to  available  operators  with  the 
skills  necessary  to  perform  the  job.  Some  jobs  that  are  in  progress  from  the  previous  time  step  can 
be  interrupted  if  a  higher  priority  job  requires  the  same  operator,  or  a  job  step  considered  to  be 
generic  can  be  interrupted  to  free  a  skilled  operator  so  they  can  move  to  a  job  requiring  their  skill, 
leaving  the  generic  job  for  someone  else. 

Products  are  created  with  the  objective  of  enabling  sensemaking 3  by  the  Consumer,  so  it  is  the 
Consumer  who  determines  the  utility  of  any  product.  Flowever  Producers  estimate  the  utility  of 
jobs  as  they  are  worked  upon  so  those  jobs  can  be  prioritized.  Jobs  are  abandoned  when  their 
utility  decays  faster  than  the  operators  can  increase  it.  Jobs  are  also  abandoned  if  they  cannot  be 
completed  by  their  drop-dead  time,  which  is  specified  separately  for  each  job.  If  a  job’s  drop-dead 
time  is  omitted  in  the  input  files,  it  will  instead  be  calculated  based  on  the  job’s  arrival  time  at  the 
queue  and  a  standard  allowable  production  time  for  that  job  type. 

2.4.2  Consumer  Logic 

The  Consumer  performs  the  direct  C2  activity  by  receiving  information  products  from  the 
Producer,  ordering  actions  to  be  taken,  and  issuing  questions  when  there  are  gaps  in  the 
Consumer’s  SA.  In  terms  of  SMOFN  execution,  the  Consumer  node’s  job  is  very  straightforward. 
Each  time  a  product  is  received  by  the  Consumer,  there  is  a  chance,  based  on  the  type  of  product 
received,  that  a  question  will  be  generated.  The  Consumer  reviews  each  product  received  and 
then  possibly,  based  on  the  set  probability  for  the  product  type,  generates  questions  after  a  certain 
delay  time.  These  questions  are  sent  to  the  Repository  to  be  passed  on  to  the  Discover  node. 


3  Sensemaking  is  defined  as  “the  process  by  which  individuals  (or  organizations)  create  an  understanding  so 
that  they  can  act  in  a  principled  and  informed  manner”  [12]. 
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2.4.3  Discover  logic 


The  Discover  node  is  responsible  for  answering  questions  generated  by  the  Consumer.  This  can 
actually  be  done  by  any  operator,  including  the  original  Consumer  or  Producer.  In  real  life,  this 
tends  to  be  done  through  a  search  for  existing  data.  In  modelling  terms,  it  is  handled  through  job 
threads  similar  to  those  used  by  the  Producer.  In  fact,  most  of  the  logical  scripting  used  by  the 
Producer  threads  is  shared  with  the  Discover  threads  except  for  a  few  important  differences.  First, 
the  Discover  logic  does  not  track  utility  because  that  will  be  determined  by  the  analysis  job 
performed  by  the  Producer  on  the  newly  discovered  data.  Also,  the  Discover  thread  either  returns 
new  data  that  is  sent  to  the  Producer  to  help  answer  the  Consumer’s  question,  or  tasks  External 
Sources  to  collect  that  data.  It  is  also  possible  for  Discovery  to  generate  both  outcomes,  meaning 
that  even  if  data  is  found  and  sent  to  the  Producer,  it  is  possible  that  more  data  is  needed,  in  which 
case  a  query  is  also  sent  to  External  Sources. 

The  actual  process  can  be  to  send  the  questions  to  others  to  resolve  or  try  to  answer  the 
information  directly.  Either  way,  if  information  is  discovered,  the  results  modify  or  add  to  the 
existing  products  and  affect  the  SA  in  the  Consumer’s  mind.  The  Discovery  process  can  be  hard 
to  quantify  because  Consumers  can  generate  internal  and  informal  questions  that  get  answered 
without  the  remainder  of  the  architecture  being  aware  of  them.  Only  if  the  initial  search  does  not 
yield  the  needed  answers  will  the  question  be  converted  into  a  formal  query. 

2.4.4  External  Sources  Logic 

The  External  Sources  node  receives  queries  from  the  Discover  node  and  is  tasked  with  finding  the 
information  that  will  be  sent  to  the  Producer  so  that  the  Consumer’s  original  question  can  be 
answered.  The  External  Sources  may: 

1 .  Already  have  the  information  and  only  need  to  find  and  deliver  it; 

2.  Collect  new  data;  or 

3.  Forward  the  query  on  to  other  External  Sources. 

Exactly  how  the  requested  information  is  found  is  not  within  the  scope  of  the  SMOFN.  What  is 
important  is  how  much  information  is  found  (in  terms  of  file  size)  and  how  long  it  takes  to  find  it. 
The  found  information  will  typically  be  in  the  form  of  raw  data,  which  is  then  sent  to  the 
Producer  to  trigger  a  new  analysis  job. 

2.4.5  Repository  Logic 

The  repository  is  the  medium  between  all  of  the  other  nodes.  Its  job  is  to  transfer  products  from 
Producers  to  Consumers,  questions  from  Consumers  to  Discoverers,  queries  from  Discoverers  to 
External  Sources,  results  from  Discoverers  to  Producers,  and  responses  from  External  Sources  to 
Producers.  The  SMOFN  handles  all  of  these  transfers  in  a  similar  manner,  with  nuances  to 
account  for  differences  between  types  of  data  or  nodes.  More  particularly,  it  also  handles  meta¬ 
information  (information  about  the  information  transferred)  relevant  for  the  receiving  node  to 
execute  its  logic  appropriately. 
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2.5  Producer-Repository-Consumer  Model 


The  above  description  assumes  the  existence  of  the  Producer-Repository-Consumer  model  [7]  to 
account  for  ways  in  which  Producers  transfer  information  through  the  repository  to  Consumers. 
The  Repository  itself  can  be  composed  of  any  conglomeration  of  servers  and  databases  but  they 
are  viewed  through  a  Graphical  User  Interface  (GUI)  that  acts  as  the  portal  allowing  the  user  to 
treat  all  the  information  as  residing  in  a  single  Virtual  Knowledge  Base  (VKB). 

This  approach  also  assumes  that  all  connectivity  takes  place  through  the  Repository  using  the 
portal  GUI  that  operators  can  customize  to  address  their  specific  needs.  The  Repository 
operational  rules  direct  the  data  from  sender  to  recipient.  Every  node  can  select  the  operational 
rules  to  automatically  push  or  pull  the  required  information  between  nodes,  or  to  allow  the 
manual  push  or  pull  by  the  appropriate  operators.  The  ability  to  set  and  test  the  interaction  of 
detailed  data  transfer  rules  within  the  simulation  provides  a  clear  indication  of  how  these 
seemingly  benign  assumptions  can  influence  the  network’s  operational  efficiency. 

Figure  4  illustrates  the  ways  in  which  Producer  and  Consumer  nodes  can  communicate  with  each 
other  and  interact  with  the  Repository.  The  most  direct  way  for  content  to  be  transferred  is  for  the 
Producer  to  push  products  directly  to  the  Consumer.  Note  that  during  the  actual  execution  the 
transfer  will  most  often  occur  over  a  network  with  the  Repository  acting  as  the  medium  to 
accomplish  this.  Alternately,  the  Producer  may  post  content  to  the  Repository  where  it  waits  to  be 
pulled  by  interested  Consumers.  The  logic  options  include  allowing  the  Producer  to  notify  the 
Consumer  that  content  is  available,  or  allowing  the  Repository  to  use  its  operational  rules  to 
decide  when  to  notify  the  Consumer,  or  leaving  it  for  the  Consumer  to  find  when  searching  for 
new  information. 
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Figure  4:  Producer-Repository-Consumer  Paths 
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3  SMOFN  Engine  in  CORE 


While  the  previous  chapter  explained  the  process  that  the  SMOFN  is  simulating,  this  chapter 
focuses  on  the  logic  controlling  the  SMOFN.  In  other  words,  we  are  moving  from  the  conceptual 
(what  is  being  simulated)  to  the  technical  (how  it  is  being  simulated). 

3.1  SMOFN  Top  Level  Description 

Figure  5  is  the  top-level  diagram  that  controls  SMOFN  execution.  It  is  intended  here  to  illustrate 
the  process  as  a  whole  however  larger  scale  views  of  each  section  of  the  diagram  are  available  in 
Annex  B  as  Figure  45  through  Figure  48.  Annex  B  also  includes  illustrations  of  lower  levels  of 
decomposition  which  are  only  incidental  to  the  discussion  here.  Figure  5  is  colour-coded  so  each 
activity  can  be  easily  cross-referenced  with  the  appropriate  node  of  the  SMOFN  OV-1  diagram  in 
Figure  3.  The  addition  of  the  new  nodes  is  the  main  difference  from  the  OPCEN  SM  in  Figure  2. 
Figure  5  is  segmented  into  five  phases  of  activity: 

1.  Simulation  Control  handles  the  process  of  incrementing  the  clock  by  one  time  step  and 
checking  for  the  end  of  the  simulation.  It  also  includes  the  input  of  scenario  data  at  the 
beginning  of  the  simulation,  before  entering  the  time  step  loop; 

2.  OPCEN  Input  simulates  the  delivery  of  information  from  the  Repository  to  OPCENs 
(Producers,  Consumers,  and  Discoverers)  and  to  External  Sources  at  the  beginning  of  each 
time  step; 

3.  OPCEN  Activity  refers  to  the  activity  within  those  nodes,  that  is  the  generation  of  questions 
by  Consumers,  the  processing  of  jobs  by  Producers  and  Discoverers,  and  the  production  of 
new  data  by  External  Sources  during  each  time  step; 

4.  OPCEN  Output  simulates  the  uploading  of  information  from  OPCENs  and  External  Sources 
to  the  Repository;  and 

5.  Simulation  Output  stores  pertinent  information  in  output  variables  after  each  time  step  and 
saves  those  variables  as  output  files  at  the  end  of  the  simulation. 

Unlike  most  activity  diagrams  created  in  CORE,  time  in  the  SMOFN  does  not  increase  as  CORE 
steps  through  the  process  from  left  to  right.  In  this  case,  time  is  actually  stopped  and  the  displayed 
left-to-right  sequence  represents  the  decision  making  process  that  takes  place  at  each  time  step. 
Once  the  decision  logic  is  completed  SMOFN  increments  time  another  step  and  repeats  the 
process. 

Another  key  difference  between  Figure  5  and  typical  CORE  behaviour  diagrams  is  that  the 
process  logic  is  not  completely  defined  simply  by  the  diagram  itself.  As  mentioned  earlier,  the 
non-serial  behaviour  of  TPPU  logic  is  not  scalable  when  modelled  by  classical  flowchart 
diagrams,  so  SMOFN  uses  scripting  embedded  within  each  activity  block  in  the  diagram  to  track 
the  state  of  each  job. 
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3.2  Logic  Within  Branches 


The  simulation  control  and  simulation  output  phases  control  the  main  branch  of  the  simulation. 
The  other  three  phases  are  divided  into  branches  controlling  the  clock  and  the  four  operational 
nodes.  The  following  discussion  lists  the  logic  branches  in  the  order  shown  in  Figure  5. 

3.2.1  Main  Branch 

The  SMOFN  logic  elements  shown  as  white  boxes  in  Figure  5  are  the  simulation  control  and 
simulation  output  phases.  When  the  simulation  starts,  the  setup  activity  runs,  reading  data  from 
input  files  and  initializing  global  variables  used  to  track  data  throughout  the  simulation.  The 
SMOFN  then  enters  a  loop  which  repeats  for  each  time  step.  First  the  Run-to-End  Check  executes 
to  see  if  the  end  of  the  simulation  has  been  reached  (this  will  occur  at  a  pre-set  time  or  when  there 
are  no  jobs  left).  If  the  end  of  the  simulation  is  reached  then  the  loop  exits  and  the  SMOFN  skips 
ahead  to  the  End-of-Run  Reporting  which  outputs  the  data  that  was  tracked  throughout  the 
simulation.  If  the  end  is  not  reached,  the  clock  increments  one  time  step  and  each  node’s  logic  is 
executed.  Afterward,  the  current  state  of  every  task  and  every  operator  is  saved  to  the  global 
variables  that  form  the  basis  of  the  simulation  output. 

3.2.2  Clock  Branch 

The  clock  activity  initiates  all  SMOFN  activity  by  incrementing  the  simulation  clock  and  sending 
the  trigger  that  starts  the  repository  branch  activity  during  each  time  step. 

3.2.3  Consume  Branch 

The  yellow  boxes  in  Figure  5  represent  the  Consume  activity  of  the  SMOFN  OV-1.  Each  time 
step,  the  Consumer  node  begins  by  receiving  products  sent  by  the  Repository.  The  “Generate 
Questions”  activity  then  goes  through  all  the  products  that  have  just  been  received  and  may 
generate  questions  based  on  those  products.  If  any  questions  are  generated,  the  delay  before  they 
are  actually  sent  is  determined  and  the  time  to  send  them  is  added  to  a  schedule.  This  delay  is 
meant  to  account  for  any  time  between  when  the  product  is  received  and  the  question  is  sent  out 
and  can  be  attributed  to  several  factors,  including:  time  to  study  the  product,  time  to  formulate  a 
question,  and  any  time  where  the  Consumer  is  engaged  in  other  activity.  As  in  real  life,  if  the 
probability  of  generating  questions  is  high  enough,  the  cumulative  demand  placed  on  other  nodes 
steadily  increases  during  the  simulation,  eventually  exceeding  their  capacity  to  respond. 

3.2.4  Produce  and  Discover  Branch 

The  Produce  and  Discover  activities  share  much  of  the  same  logic  so  their  execution  is  controlled 
together  by  the  blue  boxes  in  Figure  5.  First  a  list  of  OPCENs  is  built  and  a  loop  is  entered  that  is 
repeated  for  each  OPCEN.  The  loop  begins  by  choosing  a  new  OPCEN  and  the  “Schedule 
Processing”  activity  then  looks  at  the  job  arrival  schedule  for  that  OPCEN  and  adds  to  the  queue 
any  job  that  arrives  during  the  current  time  step.  “Utility  Decay”  then  goes  through  all  the  jobs 
and  checks  to  see  how  old  their  data  is.  If  the  age  of  the  data  is  such  that  the  utility  should 
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decrease  this  time  step  (as  explained  later  in  Section  4.2.5),  that  is  handled  here.  The  “Thread  & 
Queue  Processing”  element  goes  through  all  jobs  and  assigns  available  operators  to  jobs  in  order 
of  priority.  It  is  here  that  the  utility  of  jobs  can  increase  as  work  progresses,  or  jobs  can  be 
abandoned  if  they  cannot  be  completed  on  time  (under  the  TPPU  paradigm,  jobs  that  were 
partially  completed  when  abandoned  can  still  be  delivered  for  use  by  consumers).  Produce  and 
Discover  jobs  may  draw  from  a  single  pool  of  operators  so  when  the  SMOFN  sorts  jobs  in  order 
of  priority,  it  ignores  whether  the  job  is  related  to  Production  or  Discovery.  After  these  activities 
have  executed,  the  “Capture  Localized  Status”  element  stores  in  memory  any  data  that  must  be 
tracked  into  the  next  time  step.  This  data  includes  the  current  state  (ie.  job  assignment)  of  each 
operator  and  the  current  state  of  each  job  (ie.  completed,  abandoned,  or  some  amount  of  time 
remaining  in  a  given  job  step).  After  the  loop  has  executed  for  each  OPCEN,  the  “OPCEN 
Processing  Complete”  element  signals  to  the  Repository  that  it  can  now  execute  its  logic  for 
receiving  products  and  queries. 

3.2.5  Repository  Branch 

The  pink  boxes  represent  the  work  done  by  the  Repository  during  each  time  step.  It  is  this  branch 
that  receives  the  trigger  from  the  clock  branch  telling  it  to  begin  its  activity.  The  Repository  logic 
then  starts  by  resetting  the  global  variable  tracking  the  bandwidth  between  the  Repository  and 
each  OPCEN,  which  will  be  decremented  whenever  bandwidth  is  used  to  send  or  receive  data. 
Bandwidth  is  tracked  in  terms  of  how  much  data  can  be  transferred  during  each  time  step. 

Next,  the  Repository  checks  for  the  arrival  of  new  raw  data.  This  check  is  based  only  on 
parameters  read  into  the  model  during  setup;  raw  data  received  from  External  Sources  in  response 
to  queries  is  handled  separately.  “Send  From  Repository”  contains  the  logic  used  to  send  products 
to  the  Consumer,  jobs  to  the  Producer,  questions  to  the  Discoverer,  and  queries  to  External 
Sources.  This  activity  takes  place  before  each  of  the  other  nodes  executes  during  the  time  step  (it 
creates  the  trigger  allowing  the  other  nodes  to  start)  so  they  can  incorporate  data  as  they  receive 
it.  Similarly,  “Receive  At  Repository”  waits  until  each  node  has  completed  its  execution  for  the 
time  step  so  it  can  receive  data  as  soon  as  it  is  ready.  This  activity  receives  questions  from 
Consumers,  products  from  Producers,  queries  from  Discoverers,  and  responses  from  External 
Sources.  It  should  be  noted  that  the  Receive  and  Send  activities  of  the  Consumer  and  External 
Sources  have  no  embedded  logic  scripts.  Their  logic  is  actually  handled  within  the  Send  and 
Receive  activities,  respectively,  of  the  Repository.  They  are  shown  to  illustrate  the  Consumer  and 
External  Source  perspectives  of  what  is  taking  place. 

3.2.6  External  Sources  Branch 

Finally,  External  Sources  from  the  SMOFN  OV-1  are  simulated  with  the  red  boxes.  They  receive 
queries  from  the  Repository,  respond  to  those  queries,  and  send  the  responses  back  to  the 
Repository.  As  with  the  Consumer,  the  process  required  to  respond  to  queries  is  not  tracked  in 
detail,  only  the  amount  of  time  required  and  the  type  of  raw  data  returned  (specifically,  the  type 
of  analysis  job  that  will  be  triggered  at  the  Producer  when  it  receives  that  data)  are  currently 
handled  within  the  simulation. 
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4  SMOFN  Input  Data  Files 


One  advantage  of  the  SMOFN  is  that  the  model  itself  is  only  concerned  with  the  execution  of  the 
operational  logic.  All  operating  parameters,  such  as  the  number  of  operators  at  an  OPCEN  and 
their  skill  sets,  or  the  number  of  jobs  to  be  done,  are  read  from  data  files  during  the  setup  stage  of 
the  simulation.  This  allows  a  single  version  of  the  model  to  be  used  across  a  limitless  variety  of 
scenarios. 

The  explanations  that  follow  broadly  describe  what  is  contained  in  each  input  file  but  their 
detailed  instantiations  are  left  to  the  User’s  Manual  in  Annex  A. 

4.1  Simulation  Setup 

The  first  data  file  read  into  the  SMOFN  points  to  the  data  path  where  the  scenario  files  reside. 
The  simulation  will  prompt  the  user  to  identify  the  location  and  name  of  this  file.  It  will  then 
identify  the  path  to  all  other  files  that  need  to  be  read.  The  scenario  files  include  those  needed  to 
setup  the  simulation  and  those  used  to  describe  the  OPCENs  that  are  simulated.  The  setup  files 
include: 

1 .  The  time  at  which  the  simulation  will  stop; 

2.  The  day  of  the  week  and  time  that  is  represented  by  the  beginning  of  the  simulation; 

3.  A  switchboard  to  allow  the  analyst  to  select  values  for  a  list  of  generic  operational  rule 
settings;  and 

4.  A  list  of  OPCENs  and  the  data  paths  containing  their  setup  information. 

4.1.1  Switchboard 

There  are  six  rules  that  can  be  specified  in  the  switchboard,  three  that  are  specified  by  answering 
yes  or  no  to  a  specific  question,  and  three  that  require  numerical  answers. 

The  first,  and  simplest,  yes  or  no  question  is  whether  there  is  any  chance  of  a  job  resulting  in 
Nothing  Significant  to  Report  (NSTR).  If  yes,  the  probability  of  this  happening  is  specified  later 
as  it  is  specific  to  each  thread  type. 

The  next  question  covers  the  situation  where  a  job  would  normally  be  abandoned  because  it 
cannot  be  completed  on  time,  but  there  is  still  time  to  complete  at  least  one  more  step.  The 
question  is  whether  the  step  should  be  completed  so  that  the  product  is  as  complete  as  possible 
when  time  runs  out,  or  whether  the  job  should  be  abandoned  immediately. 

The  final  yes  or  no  question  asks  if  a  job  should  be  abandoned  when  its  utility  appears  to  be 
decaying  due  to  age  faster  than  it  is  accruing  due  to  work  performed  by  the  operator. 
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The  first  numerical  question  deals  with  the  fact  that  if  two  jobs  have  the  same  priority,  one  of 
them  may  be  treated  as  a  higher  priority  if  it  is  considered  rushed.  The  number  specified  here 
defines  the  ratio,  expressed  as  a  percentage,  of  remaining  slack  time  (the  amount  of  time  that  a 
job  can  be  ignored  and  still  be  completed  on  time)  to  remaining  job  time  at  which  a  job  is 
considered  rushed.  For  example  a  job  may  be  considered  rushed  if  its  slack  time  is  equivalent  to 
less  than  50%  of  the  time  it  will  take  to  be  completed.  If  two  jobs  of  equal  priority  are  both 
considered  rushed,  the  one  with  the  lowest  ratio  of  slack  time  to  remaining  job  time  will  be 
treated  as  the  higher  priority. 

The  last  two  questions  deal  with  a  job  step  that  is  being  restarted  after  having  been  abandoned 
between  posts.  It  is  assumed  that  the  job  step  may  be  restarted  from  the  last  post  rather  than  from 
the  beginning,  but  that  some  time  must  be  taken  by  a  new  operator  to  become  familiarized  with 
the  work  already  done.  One  question  asks  how  much  time  must  be  spent  by  a  new  operator  to 
become  familiar  with  work  already  done  before  they  can  begin  progressing  on  the  actual  job.  This 
is  expressed  as  a  percentage  of  the  amount  of  time  between  job  posts.  The  other  question 
examines  the  situation  where  an  operator  comes  back  to  his  own  work  and  asks  how  much  time 
(in  minutes)  could  that  operator  have  been  away  before  needing  to  re-familiarize  himself  with  the 
job  and  suffering  the  same  time  penalty  as  a  new  operator  would. 

4.2  OPCEN  Inputs 

The  parameters  for  each  OPCEN  are  defined  by  five  different  files  that  are  read  into  the  SMOFN. 
The  following  files  are  found  in  the  OPCEN  data  paths  that  were  read  from  the  first  simulation 
setup  file  described  in  the  previous  section: 

1 .  A  summary  of  thread  types; 

2.  The  step-by-step  definitions  of  each  job  thread; 

3.  An  events  list; 

4.  A  matrix  of  operator  skills;  and 

5.  A  set  of  utility  decay  function  definitions. 

4.2.1  Thread  Types 

The  thread  types  file  defines  the  overall  characteristics  of  each  job  type  that  is  processed  at  the 
particular  OPCEN.  The  details  specified  here  reflect  the  job  as  a  whole,  whereas  the 
characteristics  of  each  step  within  the  job  thread  are  specified  in  the  thread  definitions  file.  Each 
entry  is  identified  by  thread  name  and  priority.  It  is  important  to  note  that  in  the  case  of  specific 
jobs,  any  value  for  priority  is  acceptable  however  when  filling  in  data  for  thread  types,  it  is  not 
feasible  to  include  every  possible  value  of  priority.  Therefore,  if  an  instance  of  a  job  is  given  a 
priority  that  is  not  included  in  the  appropriate  thread  type  definition,  it  will  be  treated  as  the 
nearest  priority  value  for  which  the  thread  type  has  been  defined.  The  data  used  to  describe  a 
thread  includes  the  following  fields: 
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1 .  Percentage  of  jobs  that  will  result  in  NSTR; 

2.  Default  slack  time  for  the  job,  representing  the  amount  of  time  a  job  could  sit  idle  without 
becoming  invalid; 

3.  Number  of  steps  an  operator  can  look  ahead  to  estimate  the  expected  utility  gained  over  time 
spent  on  the  job; 

4.  Whether  the  job  is  redundant  with  other  jobs  of  its  type  (jobs  that  are  redundant  will  be 
ignored  if  another  job  of  the  same  type  is  in  progress  when  a  new  one  arrives  in  the  queue  - 
data-driven  jobs  tend  to  be  specific  to  the  newly  arrived  data,  whereas  SOP-driven  reports 
tend  to  be  redundant); 

5.  Utility  of  a  job  that  returns  NSTR.  Instinctively  this  may  be  zero,  but  there  are  certain  jobs 
where  it  is  worth  something  simply  to  know  that  there  is  NSTR;  and 

6.  The  details  of  aggregating  other  jobs  into  the  current  one.  Used  by  the  SMOFN  to  properly 
account  for  the  aggregation  of  several  completed  products  into  one  new  job.  For  example, 
several  imagery  analysis  jobs  being  reported  together  in  one  Situation  Report  (SITREP).  The 
following  details  need  to  be  specified  for  the  aggregating  job  thread: 

a.  Name  of  the  job  step  where  aggregation  will  take  place; 

b.  Types  of  completed  jobs  to  aggregate,  and  for  each  job  type: 

i.  The  amount  of  time  that  must  be  added  to  the  aggregation  step  for  each  job 
aggregated;  and 

ii.  The  percentage  of  the  aggregated  job’s  utility  that  carries  over  to  the  aggregating 
job. 

4.2.2  Thread  Definitions 

The  last  file  describes  how  the  job  threads  are  constructed,  in  terms  of  how  the  SMOFN  will 
handle  each  step  within  each  job.  This  file  uses  one  line  of  data  for  each  step  of  each  thread  type 
and  these  types  must  be  the  same,  by  name  and  priority,  as  those  listed  in  the  thread  types  file. 
Each  line  of  data  has  12  entries,  identifying: 

1 .  The  thread  type  (including  name  and  priority); 

2.  The  name  of  the  current  step,  which  must  be  unique  within  the  thread  type; 

3.  The  time  required  to  complete  the  step; 

4.  The  skill  required; 

5.  The  number  of  times  the  product’s  utility  is  updated  by  being  saved  to  the  Repository  during 
the  step  (these  are  the  “Posts”  in  TPPU); 
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6.  Whether  or  not  the  step  is  allowed  to  be  interrupted; 

7.  Three  fields  representing  the  minimum,  mode,  and  maximum  of  a  triangular  distribution  used 
to  calculate  the  utility  that  is  achieved  by  the  end  of  the  step; 

8.  The  file  size  of  the  resulting  product  (used  to  track  uploading  to  the  Repository  and 
subsequent  distribution  to  Consumers); 

9.  The  type  of  step.  This  is  specified  in  terms  of  which  logical  script  to  execute  within  the 
SMOFN  and  therefore  must  correspond  to  a  type  that  the  SMOFN  has  been  scripted  to 
understand  (these  acceptable  types  are  described  below);  and 

10.  The  name  of  the  next  step  to  move  to  after  the  current  one. 

The  “Type  of  Step”  entry  warrants  further  discussion.  Seven  types  of  steps  are  currently 
understood  by  the  SMOFN,  and  they  are  identified  here  by  number.  The  first  three  of  these  step 
types  previously  existed  in  the  OPCEN  SM  and  apply  to  both  Production  and  Discovery: 

1.  No  decision  is  made  at  the  end  of  this  step,  once  the  it  is  complete  the  job  will  simply  move 
on  to  the  next  step; 

2.  NSTR  decision:  if  the  job  is  marked  NSTR,  it  happens  at  the  beginning  of  this  step,  after 
which  all  subsequent  steps  are  skipped;  and 

3.  Final  step  of  any  Production  job,  after  which  the  job  is  marked  complete  and  removed  from 
the  queue. 

The  final  four  step  types  are  unique  to  Discovery  jobs: 

4.  A  decision  as  to  the  results  of  the  Discovery  process,  which  has  three  possible  exits,  each 
identifying  which  type  of  step  should  follow: 

a.  No  data  exists, 

b.  Desired  product  is  found,  and 

c.  Some  data  is  found  but  it  is  insufficient. 

5.  In  the  case  that  no  data  exists,  the  Discovery  job  will  create  a  request  for  new  data  that  will  be 
sent  to  External  Sources; 

6.  If  the  product  is  found,  it  must  be  analysed  and  put  in  the  context  of  the  originating  question, 
so  a  new  Production  job  is  added  to  the  appropriate  OPCEN’s  schedule; 

7.  If  insufficient  data  is  found,  then  the  Discovery  will  do  a  combination  of  the  previous  two 
steps.  It  starts  by  sending  a  request  to  External  Sources  for  more  data,  and  in  the  mean  time,  a 
new  Production  job  is  added  to  the  OPCEN  schedule  to  analyse  whatever  data  already  exists. 
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4.2.3  Events  List 


The  purpose  of  the  events  list  is  to  define  what  jobs  will  be  added  to  the  current  OPCEN’s  job 
queue,  and  when.  The  main  entries  for  each  job  are  the  thread  name,  priority,  and  the  time  at 
which  the  job  will  be  added  to  the  queue.  In  the  OPCEN  SM,  this  list  would  include  all  jobs  that 
the  OPCEN  would  be  expected  to  process  over  the  course  of  the  simulation.  In  the  case  of  the 
SMOFN  it  should  only  include  jobs  that  are  based  on  OPCEN  operating  procedures.  Other  jobs, 
based  on  the  arrival  of  new  data  are  more  appropriately  listed  in  the  schedule  of  new  jobs  that  the 
Repository  will  send  to  each  OPCEN  (described  in  the  next  section). 

The  utility  of  the  job  will  typically  decay  based  on  the  age  of  the  raw  data  the  job  is  created  from. 
To  account  for  this,  the  file  includes  a  field  to  specify  when  the  data  was  collected  so  that  the 
utility  decay  can  be  calculated  from  that  point  in  time.  Also,  each  job  has  a  standard  slack  time 
based  on  thread  type,  but  the  events  list  includes  a  field  to  set  a  specific  deadline  time  which 
overrules  the  standard  slack  time. 

4.2.4  Operator  Skills 

The  SMOFN  refers  to  the  operator  skills  matrix  to  assign  operators  in  an  OPCEN  to  queued  jobs. 
Once  assigned,  this  matrix  also  identifies  how  effectively  operators  do  their  work.  The  operator 
skills  matrix  identifies  each  operator  in  an  OPCEN  by  a  “name”  that  is  a  string  containing  only 
letters  and  numbers.  The  information  tracked  for  each  operator  includes: 

1.  Their  speed  and  quality  of  work  (both  expressed  as  percentages  where  100%  speed  means 
jobs  are  done  in  the  standard  required  time,  and  100%  quality  means  the  operator  adds  the 
expected  utility  to  jobs  they  work  on); 

2.  The  order  in  which  they  are  assigned  to  generic  work; 

3.  The  percent  chance  that  they  are  available  to  take  on  generic  work  when  they  are  not  already 
assigned  any  specific  job.  For  example,  supervisors  may  not  be  performing  any  SMOFN- 
tracked  task  but  may  be  too  busy  maintaining  SA  to  pick  up  a  generic  task;  and 

4.  A  list  of  their  skills,  beginning  with  their  primary  skill  and  allowing  up  to  ten  entries.  When  a 
queued  job  requires  a  particular  skill,  the  SMOFN  will  look  to  each  operator’s  first  skill,  then 
each  operator’s  second  skill,  and  so  on  until  an  available  operator  with  the  required  skill  is 
found. 

4.2.5  Utility  Decay  Curves 

The  utility  decay  curves  are  used  by  the  SMOFN  to  describe  how  the  utility  of  products  decreases 
as  their  data  ages.  Each  line  begins  with  a  thread  name  and  priority  (the  combination  of  which 
must  match  those  in  the  thread  types  file)  and  a  time  expressed  in  units  of  the  simulation’s  time 
steps.  Each  line  then  ends  with  three  numbers  representing  the  lower  bound,  mode,  and  upper 
bound  of  a  triangular  distribution.  The  logic  of  the  utility  decay  is  that  after  the  product  of  a 
particular  thread  type  has  aged  by  the  specified  amount  of  time  (age  is  counted  from  the  moment 
the  raw  data  was  taken),  its  potential  utility  can  be  calculated  by  the  specified  triangular 
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distribution.  The  SMOFN  logic  is  defined  so  that  potential  utility  never  increases  as  products  age, 
even  if  the  distribution  is  constructed  to  allow  it.  This  works  in  a  similar  manner  to  the  accrued 
utility  (see  [8])  except  that  it  decreases  as  a  function  of  age  instead  of  increasing  as  a  function  of 
steps  completed.  The  actual  utility  is  calculated  by  multiplying  the  utility  accrued  from  work  done 
on  the  job  by  the  potential  utility  based  on  product  age. 

4.3  Repository  Inputs 

A  separate  set  of  data  files  is  used  to  describe  the  operating  parameters  of  the  Repository  after  the 
OPCEN  initialization  data.  These  files  are: 

1 .  The  schedule  for  the  arrival  of  new  data; 

2.  The  schedule  for  the  arrival  of  new  products  created  outside  the  simulation; 

3.  A  matrix  organizing  the  delivery  of  products  to  the  appropriate  Consumers; 

4.  A  list  of  each  OPCEN’s  bandwidth; 

5.  A  list  controlling  the  generation  of  questions; 

6.  A  list  controlling  Discovery  responses  to  questions;  and 

7.  A  list  controlling  External  Sources’  response  to  queries  from  Discovery. 

4.3.1  Data  Arrival  Schedule 

The  data  arrival  schedule  is  similar  to  the  events  list  for  each  OPCEN.  This  file  is  used  to 
simulate  the  fact  that  many  jobs  within  an  OPCEN  are  triggered  by  the  arrival  of  new  data  in  the 
Repository,  rather  than  by  the  OPCEN’s  own  operating  procedures.  Each  line  specifies: 

1 .  The  time  that  the  new  data  was  created; 

2.  The  time  at  which  it  will  arrive  at  the  Repository  to  be  delivered  to  the  Producer; 

3.  The  source  of  the  data  (for  example  a  reconnaissance  unit); 

4.  The  type  and  priority  of  the  job  thread  that  will  be  generated; 

5.  The  deadline  for  the  data  analysis  job; 

6.  The  Producer  OPCEN  to  which  the  data  will  be  sent  for  analysis; 

7.  The  delivery  method  (i.e.  push  or  pull);  and 

8.  The  size  of  the  file  that  must  be  delivered. 
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4.3.2  New  Product  Arrival  Schedule 


The  schedule  of  outside  products  defines  the  arrival  of  products  from  Producers  that  are  not 
tracked  by  the  model.  Product  arrival  is  an  important  consideration  for  the  SMOFN  and  is  used  to 
simulate  how  one  OPCEN  (or  several)  reacts  to  products  created  by  other  OPCENs,  without 
having  to  model  those  OPCENs  or  their  own  product  creation  processes  in  detail.  For  example,  a 
model  of  Canada  Command  might  include  SITREPs  received  from  the  MSOCs,  without  needing 
to  simulate  the  MSOC  process  to  create  the  SITREP.  These  products  can  then  be  forwarded  to 
Consumer  OPCENs  as  though  they  were  created  within  the  simulation.  The  required  data 
includes: 

1 .  The  name  of  the  producing  OPCEN; 

2.  The  type  of  job  (including  the  priority  rounded  to  the  nearest  appropriate  thread  type); 

3.  The  specific  priority; 

4.  The  file  size  to  be  transferred; 

5.  The  time  at  which  the  original  data  was  collected; 

6.  The  time  at  which  the  product  will  arrive  at  the  Repository; 

7.  The  status  of  the  job  producing  the  product  (either  complete  or  the  end  of  a  specific  job  step, 
in  which  case  the  product  corresponds  to  the  most  recent  update); 

8.  The  utility  achieved  due  to  work  on  the  producing  job;  and 

9.  The  decayed  utility  due  to  the  data’s  age. 

4.3.3  Delivery  Matrix 

The  SMOFN  uses  the  delivery  matrix  to  identify  what  products  are  sent  from  specific  Producers 
to  specific  Consumers.  This  applies  equally  to  products  created  within  the  SMOFN  simulation  as 
well  as  to  products  identified  in  the  new  product  arrival  schedule.  This  file  is  the  main  source  of 
information  for  the  SMOFN  to  account  for  data  sharing  between  OPCENs.  Each  line  of  data 
contains: 

1 .  The  product  type; 

2.  The  name  of  the  Producer  and  Consumer  OPCENs  (only  one  Producer  and  one  Consumer  per 
line;  products  sent  from  one  Producer  to  multiple  Consumers  must  have  one  line  for  each 
Consumer); 

3.  The  percent  probability  that  a  product  of  the  given  type  will  be  sent  to  the  specified 
Consumer  when  created  by  the  specified  Producer;  and 

4.  The  method  of  delivery  (push  or  pull;  automated  or  manual). 


DRDC  CORA  TR  2009-012 


25 


4.3.4  Bandwidth 


The  bandwidth  file  is  very  simple,  containing  only  a  list  of  OPCENs  that  connect  to  the 
Repository  along  with  their  bandwidth.  This  identifies  to  the  SMOFN  the  amount  of  data  that  can 
be  transferred  between  each  OPCEN  and  the  Repository  during  a  single  time  step.  The  External 
Sources  node  must  also  be  included  here  as  a  single  separate  entry,  in  addition  to  the  specific 
OPCENs  that  are  only  recognized  by  the  Produce,  Consume,  and  Discover  activities.  Units  are  at 
the  discretion  of  the  analyst,  but  must  be  consistent  with  the  file  sizes  for  products  identified  in 
the  thread  definitions  and  the  new  product  arrival  schedule,  as  well  as  raw  data  in  the  data  arrival 
schedule. 

4.3.5  Question  Generation 

The  questions  file  draws  from  the  combinations  of  product  types  and  Consumers  that  come  out  of 
the  delivery  matrix.  This  information  is  referred  to  whenever  a  product  is  sent  to  a  Consumer  so 
that  questions  are  generated  as  appropriate.  For  each  such  combination,  the  questions  file 
identifies  to  the  SMOFN: 

1 .  The  percent  chance  that  the  Consumer  will  generate  a  question; 

2.  The  file  size  required  to  contain  that  question;  and 

3.  The  amount  of  time  that  the  Consumer  will  take  between  receiving  the  product  and  sending 
out  the  question. 

4.3.6  Discovery  Requests 

The  discovery  requests  file  is  similar  to  the  questions  file  except  that  is  referred  to  whenever 
Discovery  receives  a  question.  Based  on  the  type  of  product  that  inspired  the  question  and  the 
OPCEN  that  the  question  came  from,  this  file  identifies: 

1 .  The  probability  that  Discovery  will  provide  an  answer;  and 

2.  The  type  of  job  that  will  be  triggered  at  the  Producer  if  results  are  available. 

4.3.7  External  Response 

The  external  response  is  again  similar  to  the  questions  and  discovery  requests  files.  In  this  case, 
whenever  a  query  is  received  by  external  sources,  this  file  identifies: 

1 .  The  probability  that  they  will  respond; 

2.  The  size  of  the  file  containing  the  response; 

3.  The  time  required  to  respond;  and 

4.  The  type  of  job  that  will  be  triggered  at  the  Producer  by  the  response. 
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Part  2  -  Populating  the  SMOFN  Engine 
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5  Data  Collection  via  Process  Modelling 


The  initial  contract  concern  was  on  building  the  SMOFN  framework  so  that  the  underlying 
operational  logic  could  execute  properly.  This  meant  that  simple  notional  data  sets  were  adequate 
to  test  the  model  logic  and  demonstrate  the  dynamic  aspects  of  the  SMOFN  engine. 

The  next  concern  is  the  collection  of  the  data  required  to  populate  all  of  the  initialization  files 
described  in  Chapter  4.  This  data  must  be  representative  of  the  operating  parameters  of  any 
OPCENs  that  are  to  be  simulated,  as  the  goal  is  to  accurately  simulate  data  flow  between  these. 
Emphasis  needs  to  be  placed  on  describing  job  threads  (especially  the  Producer  steps)  that 
involve  multiple  OPCENs,  such  as  the  process  to  report  and  respond  to  events  in  theatre  or  the 
preparation  of  high-level  daily  briefs.  Another  major  component  is  the  composition  of  various 
OPCENs,  as  far  as  the  number  of  operators  on  shift  and  the  skills  they  are  trained  in.  Although 
much  of  this  data  will  be  classified,  the  SMOFN  engine  itself  remains  unclassified  as  it  is  saved 
in  a  separate  file  from  any  classified  data  which  it  would  read  upon  execution. 

This  chapter  outlines  the  method  that  the  authors  have  used,  and  recommend,  to  collect  the  data 
required  for  the  input  files  described  in  Chapter  4.  Through  this  process,  two  job  threads  were 
created  for  the  SMOFN,  which  represent  processes  carried  out  by  the  Strategic  Joint  Staff  (SJS) 
National  Defence  Command  Centre  (NDCC).  While  this  chapter  focuses  on  the  data  collection 
process,  the  NDCC  job  threads  that  were  created  are  presented  in  Chapter  6. 

5.1  Description  of  Proposed  Method 

The  planned  process  for  building  the  future  operational  architecture  of  the  CF  command  structure 
with  the  help  of  SMOFN  is  illustrated  in  Figure  6. 


Figure  6:  Planned  Operational  Architecture  Creation  Process 
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The  work  starts  with  the  analysts  converting  whatever  evidence  exists  (typically  documentation 
or  verbal  descriptions  from  operators)  of  the  current  C2  practices  into  model  form.  In  theory  these 
should  be  SOPs  that  execute  as  a  thread  from  start  to  finish.  The  actual  experience  is  that  most 
SOPs  tend  to  be  incomplete  or  inaccurate  so  their  logic  will  not  actually  execute  as  described.  The 
knowledge  gained  through  previous  work  with  the  SMOFN  engine  is  used  to  identify  and  address 
the  gaps  so  that  the  modelling  process  eventually  captures  fully  executable  threads.  These  threads 
can  then  be  used  to  create  input  files  to  expand  the  scope  of  the  SMOFN.  If  necessary,  the 
execution  logic  can  also  be  enhanced  by  incorporating  new  operational  rules  as  the  analysts 
become  aware  of  them  through  the  modelling  process.  The  resulting  model  can  then  be  used  to 
articulate  the  C2  processes  as  refined  SOPs,  which  can  also  be  used  for  further  analysis  and 
improvement. 

The  fact  that  SOPs  tend  to  be  incomplete  or  inaccurate  is  not  just  a  problem  for  the  modellers,  but 
also  for  any  operators  who  are  newly  posted  into  their  position.  The  payoff  from  their  perspective 
is  that  C2  practices  are  quickly  captured,  documented  and  converted  into  validated  SOPs  which 
can  be  passed  on  through  the  next  round  of  postings.  The  review  process  allows  the  operators  to 
increase  their  awareness  about  the  C2  processes  that  may  then  expose  deficiencies  in  current 
SOPs  and  practices.  Often  this  is  as  simple  as  operators  having  developed  their  own  methods 
which  work  better  than  those  in  the  SOP,  but  which  have  never  been  captured  on  paper.  The 
process  also  gives  the  operators  an  opportunity  to  identify  ways  to  synchronize  efforts  and  de- 
conflict  duplicative  work  that  highlights  the  time  and  resource  expenses  of  poor  C2  practises.  The 
modelling  and  analysis  also  allows  them  to  better  assess  the  impact  of  proposed  SOP  changes  and 
make  an  educated  decision  as  to  how  to  move  forward.  In  addition,  inclusion  of  these  revised 
threads  in  the  SMOFN  allows  them  to  be  analysed  from  the  perspective  of  concurrent  activities. 
The  cumulative  effect  is  to  improve  current  C2  processes  as  well  as  identify  shortcomings  that 
require  new  or  modified  technology. 

The  payoff  from  the  modeller’s  perspective  is  the  creation  of  a  more  complete  definition  of  C2 
processes,  which  leads  to  a  better  articulation  of  the  targeted  CF  C2  operational  architecture.  As 
an  example,  the  Integrated  Command  and  Control  System  (IC2S)  Project  would  use  this  process 
to  access  data  of  operational  C2  processes  that  include  previously  undocumented  practices  and 
newly  validated  SOPs  needed  to  populate  their  CF  C2  Operational  Architecture  model.  Otherwise 
IC2S  would  have  to  refer  to  existing  SOPs  that  may  be  invalid  or  out  of  date. 

The  above  process  is  also  an  important  aspect  of  the  Verification,  Validation,  and  Accreditation 
(VV&A)  of  the  SMOFN  engine.  If  the  executable  threads  captured  from  the  operators  are 
correctly  transformed  into  inputs  to  the  SMOFN,  then  the  model  should  be  able  to  replicate 
representative  results  that  have  been  observed  during  operations.  Once  the  VV&A  process  is 
complete  for  individual  threads  is  it  reasonable  to  start  analyzing  the  SMOFN  parameters  for 
cumulative  effect  of  interactions  between  threads. 
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6  Trial  of  SOP  Modelling  Process 


A  major  discussion  item  that  came  out  of  the  start  of  the  Phase  4  workshop  was  the  need  to  see 
how  the  SOP  modelling  process  actually  works.  The  consensus  was  that  it  would  be  easier  to 
understand  if  one  or  two  examples  could  actually  be  modelled  during  the  workshop.  The 
workshop  participants  then  selected  two  candidates  of  important  C2  practices;  one  had  no 
organized  SOP  while  the  other  SOP  was  considered  to  be  the  most  complex  one  that  had  been 
documented.  The  thought  was  that  if  these  two  cases  could  be  successfully  modelled  it  would 
provide  ample  evidence  as  to  the  viability  of  the  modelling  approach. 

In  each  case  the  approach  taken  was  to  capture  information  about  the  job  thread  within  CORE 
and  then  read  through  the  output  transcripts  with  the  operator  Subject  Matter  Expert  (SME)  to 
make  sure  the  model  executed  as  intended.  Once  the  threads  were  finalized,  they  could  be 
translated  into  the  format  used  to  describe  Producer  activity  in  the  SMOFN. 

6.1  Casel-eBrief 

6.1.1  Context  Leading  to  Approach 

The  first  case  was  an  undocumented  C2  practice  used  by  the  NDCC  night  watch  to  prepare  the 
daily  Electronic  Briefing  (eBrief)  for  senior  commanders.  The  actual  modelling  process  took  two 
days  of  work  by  the  SME  and  two  analysts. 

On  the  first  day  the  lead  analyst  facilitated  the  data  collection  by  querying  the  SME  about  the 
steps  in  the  process.  The  data  collection  involved  the  operator  SME  describing  the  process  step  by 
step  with  estimates  of  personnel  resources,  timings  and  duration  distributions.  The  other  analyst 
followed  the  discussion  while  entering  the  data  elements  and  proposed  logic  into  CORE. 

The  second  day  was  used  to  lead  the  SME  through  the  modelled  logic  to  correct  misconceptions 
or  articulate  key  sub-processes.  The  modelled  eBrief  logic  was  then  tested  using  CORE’S 
embedded  simulator.  The  model  ran  once  corrections  were  made  for  inconsistent  logic  and  then 
the  timeline  produced  by  the  simulator  was  checked  with  the  SME  to  see  if  the  model  actually 
executed  as  intended.  This  highlighted  a  few  cases  where  activities  were  being  handled  out  of 
order  and  these  were  easily  corrected.  It  also  highlighted  where  process  and  resource  bottlenecks 
were  disrupting  the  preparations. 

The  deliverable  was  a  DoDAF  OV-6  product  generated  within  CORE.  The  OV-6  is  the 
“Operational  Activity  Sequence  and  Timing  Descriptions”  [2]  which  shows  the  sequence  of 
operational  activities  within  an  architecture  as  well  as  how  those  activities  respond  to  received 
inputs.  The  product  included  all  of  the  diagrams  in  Annex  C  along  with  a  detailed  description  of 
the  characteristics  of  each  element  in  the  diagram,  including  values  entered  as  attributes  and 
relationships.  This  comprehensive  record  can  be  used  to  guide  the  writing  of  validated  SOPs. 
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6.1.2  Description  of  the  Modelled  eBrief  Process 


The  top-level  diagram  of  the  modelled  eBrief  process  is  illustrated  in  Figure  7  and  is  composed  of 
five  major  branches  of  parallel  activities: 

1.  Timekeeping:  A  clock  on  this  branch  creates  timed  triggers  to  initiate  activities  as  necessary; 

2.  Daily  Preparation  Process:  The  main  focus  of  activity; 

3.  Wrap-up  &  Review:  The  final  activities  used  to  get  final  approval  of  the  briefing  content; 

4.  CDS  Brief:  An  activity  to  prepare  extra  slides  for  the  weekly  briefing  to  the  Chief  of  the 
Defence  Staff  (CDS);  and 

5.  Other  e-Portions:  Extra  minor  activities  that  occur  during  preparation 

The  majority  of  the  work  in  Figure  7  is  fairly  straightforward  but  the  branch  activities  all  come 
together  at  the  red  circle  when  the  eBrief  is  reviewed  and  approved  during  a  short  period  between 
0530  hrs  and  0800  hrs. 

The  red-circled  briefing  approval  element  in  Figure  7  is  decomposed  in  Figure  8.  The  approval 
process  covers  8  serially  aligned  events  with  5  triggers  indicating  when  each  activity  begins.  This 
makes  for  a  very  intensive  process  with  very  little  time  to  handle  any  unforeseen  problems  or 
make  up  for  slippage  caused  by  prior  activities.  The  only  saving  grace  with  this  process  is  that  all 
participants  realize  the  goal  is  to  produce  a  “best  effort”  and  minor  inconsistencies  in  the  eBrief 
can  be  corrected  after  the  actual  briefing. 

The  OV-6  diagrams  for  the  other  documented  eBrief  sub-processes  are  contained  in  Annex  C. 
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Date: 

Wednesday,  February  21,  2007 

Author: 

DRDC  CORA  -  J  SORT 

Number: 

DB 

Name: 

Daily  Brief 

Figure  7:  Top  Level  Daily  SJS  NDCC  eBrief 
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Figure  8:  Final  Review  and  Approval  Process  for  SJS  NDCC  eBrief 
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6.2  Case  2  -  Casualty  Reporting 


6.2.1  Context  Leading  to  Approach 

The  second  case  describes  the  large  number  of  actions  currently  required  from  several  nodes 
when  handling  serious  casualties  during  deployed  operations.  It  is  formally  referred  to  as  the 
“SOP  Matrix  for  Action  in  the  Event  of  Death/Serious  Injury  (International  Ops)”  but  for 
simplicity  this  report  refers  to  it  as  “casualty  reporting”.  A  quick  review  of  the  documented  SOP 
showed  that  it  contains  180  activities,  listed  in  12  serials,  spread  over  7  operational  entities  as 
summarized  in  Table  2.  Note  that  the  SOP  refers  to  a  node  called  “NMR”  but  it  has  no  indication 
of  what  this  acronym  stands  for,  and  the  SME  was  not  familiar  with  it  is  not  within  the  NDCC. 

Table  2:  Distribution  of  Unit  Activities  per  Serial  as  Listed  in  SOP  Matrix 


Serial 

Total 

CQA 

NDCC 

SJS 

CEFCOM 

C/*N0SC0M 

COMDS  / 
ECS  /  LI 

NMR  (?) 

Total 

180 

28 

22 

20 

42 

19 

29 

20 

1 

14 

4 

3 

1 

2 

1 

2 

1 

2 

20 

5 

2 

3 

6 

2 

1 

1 

3 

26 

4 

7 

4 

5 

1 

3 

2 

4 

15 

3 

1 

1 

4 

2 

2 

2 

5 

25 

3 

2 

2 

5 

4 

4 

5 

6 

15 

3 

1 

1 

3 

1 

3 

3 

7 

12 

1 

1 

2 

3 

1 

2 

2 

8 

8 

1 

1 

1 

2 

1 

1 

1 

9 

12 

1 

1 

1 

4 

1 

3 

1 

9a 

3 

0 

0 

0 

0 

1 

2 

0 

10 

8 

1 

1 

1 

1 

1 

3 

0 

10a 

6 

0 

1 

1 

2 

1 

1 

0 

11 

8 

1 

1 

1 

2 

1 

1 

1 

12 

8 

1 

0 

1 

3 

1 

1 

1 

The  SOP,  as  documented,  inadvertently  implies  that  each  node  follows  its  list  of  activities  in  a 
given  order  and  that  only  one  serial  is  active  at  any  time.  In  other  words,  each  node  must  go 
through  the  same  number  of  Serials,  and  every  node  must  finish  Serial  x  before  any  node  can 
begin  Serial  x+1.  The  SOP  also  provides  no  indication  about  what  activities  can/should  be  done 
simultaneously  or  cooperatively,  or  which  activities  cannot  begin  without  first  receiving 
information  from  other  completed  activities. 

The  Casualty  Reporting  process  differs  from  the  eBrief  case  in  that  a  SOP  matrix  already  exists 
that  can  be  used  to  start  building  a  model  in  CORE.  The  analyst  prepared  an  initial  version  of  the 
model  based  on  the  SOP  matrix  that  implied  a  model  structure  as  illustrated  in  Figure  9.  The 
analyst  then  met  with  the  operator  SME  to  go  over  the  logic.  Together  they  worked  through  the 
modelled  logic  so  it  reflected  the  way  the  operators  actually  make  the  SOP  work.  They  also 
entered  any  known  attribute  and  relationship  data  associated  with  each  element. 
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Figure  9:  International  Casualty  Reporting  Model  Implied  by  the  SOP  Matrix 


DRDC  CORA  TR  2009-012 


35 


The  modelling  process  required  roughly  10  hours  spread  over  five  days  to  build  the  current 
version  of  the  model.  Table  3  shows  the  differences  between  the  SOP  matrix  version  and  the  one 
modelled  with  the  operator  SME  using  CORE.  The  process  only  changed  the  total  number  of 
activity  elements  by  about  6%  but  it  also  added  32  information  exchanges  needed  to  coordinate 
activity  between  units  (the  original  SOP  had  no  information  on  data  transferred  between  nodes  or 
activities).  Of  those  information  exchanges,  30  behaved  as  triggers  where  the  information  must  be 
sent  before  the  receiving  activity  can  proceed.  The  two  exceptions  involve  information  being  sent 
from  Deployed  Ops  and  NMR  to  Canadian  Expeditionary  Forces  Command  (CEFCOM),  and  are 
identified  by  the  asterisks  (*)  in  Table  3. 

Table  3:  Comparison  of  SOP  Matrix  and  SME  Modelled  Activities  &  Triggers 


SOP  Listed 

Modeled 

T riaoers  and  Data  T ransfers  That  Were  Added 

Operational  Node 

Activities 

Activities 

Total 

Out 

In 

Total 

180 

168 

32 

14 

18 

Deployed  Ops  (CDA) 

28 

30 

7 

6* 

1 

NDCC 

22 

20 

7 

1 

6 

SJS 

20 

17 

3 

1 

2 

CEFCOM 

42 

41 

9 

3 

6* 

CANOSCOM 

19 

18 

2 

1 

1 

COMDS/ECS/L1 

29 

26 

3 

1 

2 

NMR 

20 

16 

1 

1* 

0 

6.2.2  Description  of  the  Modelled  Casualty  Reporting  Process 

Figure  10  illustrates  the  top  level  of  the  modelled  casualty  reporting  process,  based  on  the  SME 
interviews.  It  draws  from  Figure  9  in  that  it  identifies  the  Serials  in  order;  however  several  of 
those  Serials  have  been  combined  as  they  can  be  progressed  simultaneously.  The  only  real  time 
restrictions  are  that  Serials  1  through  8  must  be  completed  before  the  casualties’  arrival  at  the 
airport  of  disembarkation  (APOD),  Serial  9  must  be  completed  between  arrival  at  APOD  and 
movement  of  the  casualties,  and  Serials  10  through  12  must  be  completed  after  the  movement.  As 
shown  in  Figure  9,  the  SOP  versions  of  Serials  9  and  10  contain  two  variations  based  on  whether 
the  casualties  in  question  involve  death  and  the  transport  of  human  remains  (HR)  or  injury  and 
the  transport  of  live  casualties  (Cas).  These  variations  are  maintained  in  Figure  10,  but  a  third 
branch  is  added  to  allow  for  the  cases  involving  a  combination  of  casualties  of  both  categories. 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

IP 

Name: 

Action  in  the  Event  of  Death/Serious  Injury  -  International  Ops  -  Parallel  Processing 

Figure  10:  Top  Level  International  Casualty  Reporting  Model  (SME  Version) 

Figure  1 1  shows  the  first  level  decomposition  of  Serials  1-8,  the  circled  activity  in  Figure  10.  It  is 
broken  down  by  organization  to  show  that  each  of  these  organizations  performs  their  activities 
independently.  However,  several  information  exchanges  must  be  completed  between 
organizations  in  order  for  them  to  fulfil  their  responsibilities.  These  information  triggers  are 
represented  by  the  green  bubbles  in  Figure  1 1 . 
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Figure  11:  International  Casualty  Reporting  Model  Showing  Unit  Interactions  in  Serials  1-8 
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Figure  12  illustrates  the  activities  undertaken  by  the  Deployed  Ops  team  in  serials  1  through  8, 
represented  at  the  higher  level  by  the  circled  box  in  Figure  11.  The  dashed  red  lines  and  numbers 
show  how  the  activities  are  split  between  serials  (no  activities  are  shown  for  Serial  8  as  Deployed 
Ops  only  has  responsibility  to  maintain  SA  in  the  SOP  Serial  8).  Note  that  some  serials  are  done 
in  parallel  or  even  out  of  order  (eg.  the  lockdown  based  on  Serial  1  is  only  complete  after  Serial 
2). 

The  white  activity  boxes  in  Figure  12  represent  activities  that  existed  in  the  original  serial  version 
of  the  model  (note  the  IS  in  the  numbering  scheme,  representing  International  -  Serial).  The 
yellow  elements  were  added  so  the  SOP  logic  would  be  more  realistic  and  are  unique  to  this 
version  of  the  model  (their  numbering  scheme  contains  IP  for  International  -  Parallel). 

The  process  as  modelled  indicates  that  the  procedure  that  operators  actually  follow  works  in  a 
very  different  way  than  the  existing  SOP  documentation  would  suggest.  The  full  model  is 
illustrated  in  Annex  D. 
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Figure  12:  Casualty  Reporting  Within  The  Internationally  Deployed  Unit  During  Serials  1-8 
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6.3  Findings  of  the  Trial 

Both  trial  cases  successfully  demonstrated  how  to  quickly  build  and  validate  detailed  models  with 
operator  SMEs.  The  results  were  much  better  articulated  C2  processes  than  existed  before  and 
they  provided  a  means  to  test  a  broad  range  of  process  options.  The  added  bonus  of  using  CORE 
was  that  formatted  DoDAF  product  documents  could  be  automatically  generated  for  whatever 
data  was  entered  into  the  model.  This  gives  the  SMEs  something  to  take  away  as  a  basis  for 
documenting  a  revised  SOP. 

The  trial  results  indicate  that  the  process  of  reviewing  a  few  key  SOPs  should  take  only  a  few 
days  or  weeks.  The  results  of  these  trial  cases  were  briefed  to  7th  Canadian  Forces  Operations 
Centre  Conference  (CFOCC)  and  were  well  received.  Although  feedback  was  positive,  no 
commitments  have  been  made  by  the  Operational  Commands  to  provide  support  for  future  work. 
Elowever,  follow-up  by  Joint  Command  Decision  Support  for  the  21st  Century  (JCDS21)  led  to  a 
collaborative  effort  to  model  further  C2  operational  architecture  segments,  including  the  Canada 
Command  Rapid  Response  Action  Planning  process,  the  Combined  Forces  Air  Component 
Command  (CFACC)  National  Aerospace  Planning  Process  (NAPP),  and  SOPs  related  to  security 
at  the  Vancouver  2010  Olympic  Games. 

There  are  several  SOPs  that  have  been  suggested  as  future  candidates  to  be  included  in  the 
SMOFN,  on  the  grounds  that  the  SMEs  believed  those  processes  could  be  improved  if  they  were 
properly  articulated  and  documented.  These  would  be  given  the  same  treatment  as  the  eBrief  and 
Casualty  Reporting  processes.  The  list  is  presented  in  Annex  E. 

The  greatest  challenge  in  implementing  SMOFN  will  come  from  the  need  to  have  assured  access 
to  operator  SMEs.  They  are  the  key  to  collecting,  collating  and  validating  the  full  range  of  C2 
process  threads.  Unfortunately,  these  same  operator  SMEs  are  also  the  resource  in  greatest 
demand  for  ongoing  operations.  The  staffs  are  investigating  how  to  support  the  review  of  their 
existing  SOPs  in  order  to  document  the  C2  processes  needed  to  support  the  future  operational 
architecture. 

The  utility  of  C2  process  modelling  has  been  demonstrated.  It  is  now  for  each  Command  to 
decide  if  they  want  to  commit  to  the  modelling  of  their  SOPs.  Those  that  participate  will  have  to: 

1 .  Submit  a  prioritized  list  of  SOP  threads  to  be  modelled; 

2.  Assign  SMEs  to  each  SOP  thread  by  name  (SMEs  must  be  available  for  several  short  sessions 
and  should  be  same  ones  who  will  re-write  SOPs); 

3.  Review  SOP  models  as  they  are  completed;  and 

4.  Use  the  new  SOP  models  as  the  basis  for  revised  SOP  documentation. 

The  final  step  in  the  modelling  involves  converting  the  C2  process  threads  to  SMOFN  data  input 
file  format.  A  portion  of  this  has  already  been  demonstrated  using  the  above  trial  cases  by 
decomposing  the  threads  into  simple  sub-jobs  and  then  linking  them  together.  The  manual 
conversion  of  threads  to  input  files  is  a  significant  test  of  the  completeness  of  the  thread 
modelling,  as  many  details  of  the  processes  are  required  by  the  SMOFN  and  the  modelled  thread 
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needs  to  be  well  understood  by  the  person  doing  the  conversion.  The  automation  of  this  process  is 
left  for  a  future  project  to  resolve. 

6.4  Description  of  Proposed  Approach 

Based  on  the  experience  of  the  two  modelled  SOPs,  JSORT  recommends  the  steps  outlined  below 
as  the  method  to  collect  further  data.  This  process  assumes  the  SMEs  are  familiar  with  the  basic 
characteristics  of  Enhanced  Functional  Flow  Block  Diagrams  (EFFBDs)  in  CORE.  This  is  either 
accomplished  by  a  prior  exposure  to  the  same  style  of  diagrams  or  having  the  analyst  brief  a  short 
introductory  example.  The  method  that  JSORT  proposes  to  follow  when  modelling  SOPs  and  C2 
Practices  is  as  follows: 

1.  If  SOP  documentation  is  available,  the  analysts  build  an  initial  model  based  on  that 
documentation.  This  allows  them  to  learn  about  the  topic  so  they  can  better  lead  discussions, 
and  it  also  provides  a  starting  point  from  which  to  build  the  true  process  model,  saving  a 
significant  amount  of  the  SMEs’  time  as  they  do  not  need  to  be  present  to  build  a  model  from 
scratch.  If  no  previously  documented  SOP  is  available,  the  entire  model  must  be  populated 
based  on  SME  descriptions  of  their  work  so  extra  interview  sessions  will  be  required; 

2.  Analysts  conduct  several  short  sessions  with  SMEs  to  present,  and  receive  feedback  on,  the 
model  as  built.  Operators  describe  what  they  do  in  order  to  expand  the  SOP  or  correct  errors; 

3.  Once  the  process  diagrams  are  considered  accurate,  SMEs  provide  estimated  values  such  as 
the  amount  of  time  or  number  of  people  required  to  complete  various  activities; 

4.  Analysts  run  the  simulation  of  the  modelled  process  to  confirm  that  it  executes  as  expected, 
and  fix  any  issues  that  are  identified  in  the  process; 

5.  The  steps  involving  SME  input  can  be  repeated  with  other  SMEs  in  order  to  focus  on 
different  aspects  within  the  model; 

6.  Analysts  generate  a  report  that  operators  can  use  to  revise  their  SOP  documentation,  and 
which  the  analysts  keep  a  copy  of  to  adapt  as  input  to  the  SMOFN. 
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7  Conclusions  and  Recommendations 


A  few  significant  conclusions  have  been  drawn  from  the  SMOFN  modelling  experience,  as 
described  in  detail  in  this  paper. 

The  SMOFN  has  achieved  its  goal  of  extending  the  detailed  OPCEN  SM  model  logic  across 
multiple  nodes,  each  with  their  own  jobs  and  resources  but  also  with  the  ability  to  share 
information.  This  information  sharing  takes  place  through  the  net-centric  virtual  Repository, 
whose  operational  logic  successfully  controls  the  interaction  of  information  between  the  various 
operator  perspectives  (i.e.  producer,  consumer  and  discovery)  as  well  as  between  different 
OPCENs  within  the  SMOFN. 

Typical  OV-6  diagrams  and  other  simulations  as  usually  employed  are  limited  in  scope  and 
flexibility  by  only  being  able  to  model  what  is  built  directly  into  them.  On  the  other  hand, 
SMOFN  reads  the  desired  organizational  structure  and  operational  logic  from  data  files  each  time 
the  simulation  is  started,  allowing  it  to  be  both  scalable  and  flexible.  This  also  allows  any  details 
of  the  SMOFN  itself  to  remain  unclassified,  even  though  the  files  that  it  uses  at  input  may  contain 
classified  data. 

The  process  of  gathering  data  for  process  threads  has  been  demonstrated  to  be  both  quick  and 
effective,  requiring  a  few  days  or  weeks  to  produce  a  functioning,  validated  model.  The  major 
limitation  noted  so  far  is  the  availability  of  SMEs  to  provide  the  operational  context,  and  no  SME 
hours  have  been  committed  by  the  operational  commands  for  future  work.  This  is  expected  to 
continue  to  be  the  biggest  implementation  hurdle  to  building  faithful  simulation  and  executable 
operational  architectures.  On  the  other  hand,  the  SME  interaction  has  produced  immediate  results 
(in  the  form  of  DoDAF/DNDAF-compatible  products)  that  can  be  used  by  the  SMEs’  home 
organizations  as  the  basis  for  writing  proper  SOPs. 

Our  paper  on  the  OPCEN  SM  [7]  included  a  discussion  of  the  metrics,  such  as  variations  in  the 
job  completion  rate,  that  can  be  used  to  evaluate  different  model  configurations  (ie.  sets  of  input 
files).  The  output  files  of  the  SMOFN,  like  the  OPCEN  SM,  contain  an  account  of  the  state  of 
every  active  job  and  operator  at  every  time  step,  the  only  addition  being  the  specification  of  the 
OPCEN  where  those  jobs  and  operators  are  located.  The  same  metrics  that  were  available  to  the 
OPCEN  SM  are  therefore  still  available  to  the  SMOFN,  and  are  still  relevant  on  its  larger  scale. 

The  SMOFN  engine  is  a  viable  simulation  of  OPCEN  operations  and  interactions.  Although  a 
large  amount  of  data  will  be  required  to  make  the  model  reflective  of  real  processes,  JSORT’s 
recommendation  is  that  the  SMOFN  should  be  used  as  a  testbed  for  potential  changes  to 
operational  procedures.  To  make  the  input  data  as  manageable  as  possible,  it  may  be  possible  to 
create  a  program  that  converts  threads  modelled  in  CORE  to  the  input  files  required  by  the 
SMOFN.  This  may  be  facilitated  by  the  fact  that  CORE  is  able  to  export  all  information  pertinent 
to  the  threads  as  xml.  To  make  the  simulation  and  its  results  as  realistic  as  possible,  it  is  also 
recommended  that  the  necessary  SME  hours  be  made  available  as  a  precondition  for  modelling 
processes  to  any  degree  of  fidelity.  This  investment  of  time  would  make  SMOFN  a  valuable  tool 
in  studying  how  the  CF  does,  and  potentially  could,  operate. 
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Annex  A  SMOFN  User  Manual 


Each  phase  of  the  modelling  contract  included  the  production  of  a  user  manual  providing 
instructions  on  installing  and  running  the  SMOFN.  The  latest  version  is  included  here  for 
reference.  It  is  divided  into  two  main  sections:  the  initial  setup  of  the  SMOFN  engine,  and  the 
scenario-specific  simulation. 

A.1  Setup 

This  section  describes  the  initial  setup  of  the  SMOFN.  This  requires  the  files  “Scripts.zip”, 
“Initialization.zip”,  and  “SMOFN.xml”  which  can  be  provided  electronically.  Note  that  this 
manual  assumes  the  typical  installation  of  CORE  such  that  the  installation  directory  is 
“C:\Program  FilesWitech  Corporation\CORE  Workstation  50”.  Also  note  that  in  Windows,  any 
instances  of  “%usemame%”  below  will  be  automatically  replaced  with  the  name  of  the  user 
currently  logged  in. 

A.1.1  Install  the  scripts: 

The  SMOFN  engine  uses  external  scripts  to  calculate  the  values  for  product  utility  and  utility 
decay.  These  scripts  must  be  installed  on  the  user’s  computer  to  execute  the  SMOFN  engine. 
Install  the  scripts  to  the  CORE  Reports\50  Reports\User\SM  folder  as  follows: 

1)  Copy  the  "scripts.zip"  file  to  folder: 

C:\Program  FilesWitech  Corporation\CORE  Workstation  50\Reports\50  ReportsYUser 

2)  Once  there,  unzip.  The  scripts  should  now  be  installed  in  subfolder  SM.  The  full  path  to  the 
scripts  is: 

C:\Program  FilesWitech  Corporation\CORE  Workstation  50\Reports\50  Reports\User\SM 


A.1. 2  Install  Initialization  Files: 

3)  Copy  the  "Initialization.zip"  file  to  your  folder  where  you  keep  your  input  files,  such  as: 
C:\Documents  and  Settings\%usemame%\My  Documents\CORE\SMOFN 

4)  Once  there,  unzip.  The  files  should  now  be  installed  in  subfolder  Initialization.  The  full  path  is: 
C:\Documents  and  Settings\%usemame%\My  Documents\CORE\SMOFN\Initialization 

5)  Fix  the  path  in  file  Sl-Datapath.txt  to  reflect  your  configuration. 

A.1. 3  Load  the  SMOFN  project  in  CORE: 

6)  Focate  the  file  SMOFN.xml  and  copy  this  file  to  the  folder  where  you  keep  CORE  exports, 
such  as: 

C:\Documents  and  Settings\%usemame%\My  Documents\CORE 
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7)  Start  CORE  and  login. 

8)  In  CORE'S  Project  Explorer,  go  to  File,  Import 

9)  In  the  resulting  Import  File  dialog  box,  navigate  to  the  folder  where  you  saved  the  file 
SMOFN.xml,  select  the  file  and  click  Open.  The  XML  import  wizard  opens.  Click  Next  twice. 
NOTE:  At  Step  2,  if  you  already  have  a  project  named  SMOFN  (ie.  from  a  previous  import),  it  is 
*STRONGLY*  recommended  that  you  create  a  new  project  rather  than  import  into  an  existing 
project.  At  Step  3  of  3,  click  Import. 

A.2  Simulation  Procedure 

Simulation  execution  consists  of  scenario  development  and  subsequent  model  execution.  Scenario 
development  is  the  process  of  creating  the  set  of  input  files  required  by  the  simulation.  Although 
the  files  read  by  the  SMOFN  are  tab-delimited  text  files  (extension  .txt),  it  has  been  the  authors’ 
practice  to  create  and  edit  them  as  a  spreadsheet  and  copy  the  final  versions  to  text.  This  is  often 
done  using  an  Excel  workbook  with  individual  worksheets  dedicated  to  each  of  the  input  files. 
Scenario  development  can  also  be  accomplished  by  modifying  a  previous  set  of  text  input  files, 
but  the  potential  for  file  format  errors  makes  it  far  more  prudent  to  generate  new  files  from  the 
workbook. 

The  simulation  requires  a  minimum  of  seventeen  text  files.  The  files  are  organized  in  three 
groups:  A  set  of  files  that  describe  general  scenario  parameters,  a  set  of  files  (which  may  be 
duplicated)  that  describe  the  aspects  of  one  operations  center,  and  a  set  of  files  that  describe  the 
repository.  The  files  that  describe  scenario  parameters  are: 

•  SI  -Datapath.txt 

•  S2-SimDuration.txt 

•  S3-DayTime.txt 

•  S4-Switchboard.txt 

•  S5-OpCenters.txt 

The  following  five  files  articulate  the  characteristics  and  events  for  one  operations  center,  and  can 
be  repeated  for  additional  operations  centers  as  appropriate.  Because  the  file  names  are  fixed, 
each  individual  operations  center’s  file  sets  need  to  be  located  in  separate  directories. 

•  01-ThreadTypes.txt 

•  02-ThreadDefmitions.txt 

•  03-Events. txt 

•  04-SkillsMatrix.txt 

•  05-DecayCurves.txt 
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The  Repository  folder,  located  beneath  the  primary  scenario  folder,  contains  the  following  files 
used  to  initialize  Repository  data  delivery  and  to  provide  information  on  routing,  bandwidth,  and 
probabilities  for  Repository  functions: 

•  Rl-ExtemalData.txt 

•  R2-ExtemalProducts.txt 

•  R3-Delivery.txt 

•  R4-Bandwidth.txt 

•  R5-Questions.txt 

•  R6-DiscoveryRequests.txt 

•  R7-ExtemalResponse.txt 

A.2.1  Scenario  Development  -  Scenario  General  Parameters 

Scenario  general  parameters  are  those  initialization  parameters  that  are  either  applicable  across 
the  entire  simulation,  like  the  Switchboard  entries,  or  are  necessary  for  the  initialization  routines 
to  establish  file  paths,  time,  and  durations  that  are  required  to  set  up  the  simulation.  There  are  five 
files  in  this  group,  and  these  need  to  be  located  in  the  root  (the  folder  identified  in  the  input  file 
Sl-Datpath.txt)  folder  for  the  scenario,  with  the  exception  of  the  file  Sl-Dtapath.txt  itself.  The 
convention  is  to  put  this  file  in  the  root  folder  also,  but  this  is  not  required. 

•  Sl-Datapath.txt 

•  S2-SimDuration.txt 

•  S3-DayTime.txt 

•  S4-Switchboard.txt 

•  S5-OpCenters.txt 

Sl-Datapath.txt 

•  The  file  Sl-Datapath.txt  consists  of  a  single  entry  with  the  full  path  to  the  remainder  of  the 
initialization  files,  as  in  the  following  example: 

♦  C:\Documents  and  Settings\%usemame%\My  Documents\CORE\SMOFN\ 

Initialization 

♦  Ensure  that  the  entry  includes  the  trailing  ‘V  character  and  nothing  beyond. 

•  The  file  Sl-Datapath.txt  can  be  located  wherever  the  user  prefers,  but  the  remaining  general 
properties  files  must  be  located  at  the  path  specified. 

•  The  file  structure  from  this  example  is  shown  in  Figure  13. 
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^  Initialization 

□lx 

File  Edit  View 

Favorites  lools  Help 

pF 

Back  * 

5T  y  Search 

» 

M  Folders 

|  Address  |^|  I:\My  Documents\CORE\SMOFN\Initialization  v  Q  Go 

IC^OpCen.l 
ICi|OpCen.2 
tj|OpCen.3 
irA  Repository 

ID  Sl-Datapath.txt 

ID  S2-SimDuration.txt 
ID  S3-DayTime.txt 

D  S4-Switchboard.txt 

D  S5-OpCenters.txt 

9  objects 

898  bytes 

*  j  Local  intranet 

Figure  13:  Folder  structure  example 


•  Suggestion:  keep  Sl-Datapath.txt  and  the  remaining  initialization  files  collocated  so  that  all 
associated  files  for  any  given  scenario  are  aggregated  for  further  analysis  and  historical 
record  keeping. 

•  Results  files  will  be  placed  in  the  same  folder  as  the  initialization  files. 

52- SimDuration.txt 

•  The  file  S2-SimDuration.txt  is  a  single  entry  file  with  simulation  duration  time  in  the 
format:  days:hours:minutes.  For  example,  00:03:00  results  in  a  simulation  that  ends  0  days, 
3  hours,  0  minutes  after  starting  (simulation  time). 

NOTE:  The  simulation  may  complete  prior  to  the  time  entered  in  S2-SimDuration.txt.  This  will 

occur  if  there  are  no  remaining  inputs  in  the  schedules  for  any  of  the  operations  centers. 

53- DayTime.txt 

•  The  file  S3-DayTime.txt,  show  in  Figure  14,  contains  two  entries.  The  first  is  a  day  of  the 
week  (Monday,  Tuesday,  Wednesday,  Thursday,  Friday,  Saturday,  or  Sunday).  The  second 
is  clock  time  (00:00  through  23:59).  In  the  example  below,  the  scenario  starts  at  23:55  on 
Wednesday. 


Figure  14:  Simulation  Start  Time  Example 
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S4-Switchboard 

•  The  file  S4-Switchboard.txt,  shown  in  Figure  15,  provides  control  features  for  specific 
aspects  during  the  simulation  execution 

•  See  column  B  definitions  for  each  item: 


Figure  15:  S4-Switchboard  Example 

•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 

Save  with  the  file  name:  S4-Switchboard.txt 

S5-OpCenters.txt 

•  The  file  S5-OpCenters.txt,  shown  in  Figure  16,  contains  a  single  line  entry  for  each 
operations  center  included  in  the  scenario.  Each  entry  is  composed  of  two  parts:  the  name  of 
the  OPCEN  and  the  path  to  the  folder  containing  the  initialization  details  for  that  OPCEN. 


P  S5-OpCenters.txt  -  Notepad  fn~  X 


File  Edit  Format  View  Help 

JTFA  l:\My  Document s\coRE\SMOFN\lnitialization\opcen.l\ 
cancom  i:\My  Document s\coRE\SMOFN\lnitialization\Opcen. 2\ 
jtfp  l:\My  Document s\coRE\SMOFN\lnitialization\opcen. 3\ 


Figure  16:  S5-OpCenters.txt  Example 
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The  above  S5-OpCenters.txt  file  reflects  the  folder  structure  in  Figure  13.  The  OPCEN-specific 
initialization  files  are  in  each  of  the  subordinate  folders  (i.e.  OpCen.l).  The  contents  of  the 
OpCen.l  folder  are  shown  in  Figure  17.  Although  the  data  would  likely  be  different,  the  file 
names  under  any  OPCEN  folder  would  be  the  same  as  in  this  example. 


ft  OpCen.l 

D'n  x 

File  Edit  View  Favorites 

Tools 

Help 

V 

©Back  ’  ©  ^ 

Search  Folders 

X“?  ” 

Address  Q  I:\My  Documents\CORE\SMOFN\Initiali2ation\OpCen.l 

V  0GO 

Name 

Size  Type 

Date  Modified 

0  01-ThreadTypes.txt 

1  KB  Text  Document 

2007-02-21  15:16 

If]  02-ThreadDefinitions.txt 

5  KB  Text  Document 

2007-02-23  07:48 

ifl  03-Events. txt 

1KB  Text  Document 

2007-02-26  15:28 

If)  04-SkillsMatrix.txt 

1KB  Text  Document 

2006-06-01  07:25 

If)  05-DecayCurves.txt 

1KB  Text  Document 

2007-03-01  18:54 

5  objects 

7.29  KB  *  J  Local  intranet 

Figure  17:  OPCEN  1  Folder  Contents 
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Snapshot  Interval 

•  This  value  represents  the  number  of  simulation  minutes  between  snapshots  (the  contents  of 
what  will  be  written  as  Results) 

•  To  change  it,  open  the  SMOFN  project  in  CORE  and  locate  the  Resource  named  Snapshot 
Interval.  Its  Property  Sheet  window  is  reproduced  in  Figure  18.  Set  the  Initial  Amount  to  the 
desired  interval 

♦  Smaller  intervals  result  in  more  detail,  larger  output  files. 

♦  Larger  numbers  result  in  less  detail  and  smaller  output  files. 


Figure  18:  Setting  the  Snapshot  Interval 


A.2.2  Scenario  Development  -  Operations  Centers 

Each  Operations  Center  requires  a  set  of  input  files  to  establish  the  specific  parameters  for  that 
center.  These  are: 

•  01-ThreadTypes.txt 

•  02-ThreadDefmitions.txt 
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•  03-Events.txt 

•  04-SkillsMatrix.txt 

•  05-DecayCurves.txt 

These  files  must  be  collected  within  one  folder  as  shown  in  Figure  17. 

Multiple  Operations  Centers  for  a  given  scenario  can  be  located  anywhere,  but  the  recommended 
approach  is  to  collect  all  the  referenced  Operations  Centers,  each  in  a  separate  folder,  under  the 
scenario  root  folder,  as  shown  in  Figure  13  and  Figure  16. 

Ol-ThreadTypes 

•  The  file  01-ThreadTypes.txt,  shown  in  Figure  19,  describes  the  nominal  thread  attributes 
used  by  the  simulation 

•  Entries  are  in  the  format: 

♦  Thread  Name,  Standard  Priorities,  Fraction  NSTR,  Slack  Time,  Took  Ahead, 

Redundancy,  NSTR  utility  (%),  Step  where  other  jobs  are  incorporated,  Job 

incorporation  details,  where: 

■  Thread  Name  identifies  the  basic  job  thread: 

■  Standard  Priorities  identifies  the  priority  of  the  basic  job  thread 

■  Fraction  NSTR  identifies  the  percentage  of  input  events  (by  thread  type  and 
priority)  which  will  be  treated  as  having  Nothing  Significant  To  Report  (NSTR) 

■  Slack  Time  is  the  initial  excess  time  allowed  before  work  on  a  given  product  is 
halted,  and  is  expressed  in  minutes 

■  Took  Ahead:  The  integer  number  of  steps  to  look  forward  when  determining 
potential  utility  to  be  gained.  Used  in  determining  when  to  abandon  jobs. 

■  Redundancy:  either  a  yes  or  no  value  is  entered.  Used  to  determine  if  subsequent 
events  of  the  same  type  occurring  while  an  existing  thread  is  in  process  are 
ignored. 

■  NSTR  utility  (%):  Integer  value  representing  the  percent  utility  of  knowing  that 
there  is  Nothing  Significant  To  Report,  should  that  be  the  case. 

■  Step  where  other  jobs  are  incoiporated:  Defines  the  step  of  the  specific  thread 
where  other  products  are  incorporated.  The  value  ‘nil’  is  used  when  there  is  no 
incoiporation  taking  place  within  the  thread.  NOTE:  This  step  name  must 
correspond  with  a  step  name  defined  in  the  input  file  02-ThreadDefmitions.txt 

■  Job  incorporation  details:  A  list  of  the  thread  types  to  be  incoiporated.  The  list  is 
composed  of  three  attributes  for  each  thread  type  incoiporated:  Thread  name 
(including  priority),  number  of  minutes  added,  and  percent  contribution.  Multiple 
thread  types  are  allowed,  separated  by  tabs. 
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Figure  19:  01  -ThreadTypes  Example 

•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 

•  Save  with  the  file  name:  01-ThreadTypes.txt 

02-ThreadDefinitions 

•  The  file  02-ThreadDefmitions.txt,  shown  in  Figure  20,  contains  the  definitions  of  each  step 
in  each  job  thread  as  required  for  interpretation  by  the  SMOFN. 

•  Entries  are  in  the  format: 

♦  Thread  Name,  Priority,  Step  Name,  Duration,  Skill,  Posts,  Interrupts,  lowerBound, 

Peak,  upperBound,  Step  Type,  Next  Step,  where: 

■  Thread  Name  identifies  the  basic  job  thread 

■  Priority  identifies  the  priority  of  the  basic  job  thread 

■  Step  Name:  identifies  the  step  within  the  thread.  These  names  will  be  reflected  in 
the  results  files  and  should  reflect  the  activity  of  the  step  performed.  The  one 
exception  is  that  a  thread  definition  begins  with  the  step  name  START.  Step 
names  must  be  unique  within  each  combination  of  Thread  Name  and  Priority. 

■  Duration:  an  integer  value  representing  the  nominal  duration  of  the  step  in 
minutes. 

■  Skill:  the  skill  required  to  perform  the  step.  The  skill  name  should  be  “G”  for 
generic,  or  consistent  with  one  of  the  Skills  identified  in  input  file  04- 
SkillsMatrix,  otherwise  no  operator  can  be  assigned  to  the  job  step. 
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■  Posts:  an  integer  number  representing  the  number  of  times  information  is  posted 
to  the  repository  during  the  step. 

■  Interrupts:  indicates  whether  the  step  is  interruptible.  Enter  either  a  0  (not 
interruptible)  or  a  1  (interruptible). 

■  lowerBound,  Peak,  upperBound:  three  integer  values  defining  the  triangular 
distribution  of  utility  accrued  by  the  end  of  the  associated  step.  For  each  step  the 
values  must  conform  to  the  expression:  lowerBound  <  Peak  <  upperBound. 

■  Product  Size:  an  integer  value  representing  the  file  size  of  the  final  product 
uploaded  to  the  Repository. 

■  Step  Type:  Currently  seven  step  types  are  defined.  All  normal  thread  steps  are 
step  Type  1.  Step  Type  2  defines  an  NSTR  decision  point.  Step  Type  3  is  the 
final  step  of  a  production  job.  Step  Types  4  through  7  handle  the  results  of  a 
discovery  thread,  as  described  in  Section  4.2.2.  These  should  normally  only 
appear  as  shown  below  in  Figure  2 1 . 

■  Next  Step:  the  name  of  the  next  step  in  the  thread.  Step  names  entered  here  must 
appear  in  the  Step  Name  column.  The  last  step  in  a  thread  sequence  must  show 
the  Next  Step  entry  as  COMPFETE. 


Figure  20:  02-ThreadDefmitions  Example 


•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 

•  Save  with  the  file  name:  02-ThreadDefinitions.txt 
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NOTE:  The  Discovery  thread  is  a  special  case  of  a  defined  thread,  as  shown  in  Figure  21.  Do  not 
alter  the  highlighted  entries  without  first  understanding  the  interaction  between  these  steps  and 
the  implementation  in  Thread  &  Queue  Processing  in  the  CORE  SMOFN  engine. 


Figure  21:  02-ThreadDefinitions  with  Discovery >  Thread  Highlighted 
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03-Events 


•  The  file  03-Events.txt,  shown  in  Figure  22,  is  a  listing  of  the  input  events  for  the  simulation 

•  Entries  are  in  the  format: 

♦  Job  Number,  Collect  and  Arrive  Time,  Event  Type,  Priority,  and  Deadline,  where: 

■  Job  Number:  must  be  sequential,  starting  at  1 

■  Collect  Time:  in  the  fonnat  days:hours:minutes  from  the  start  of  the  simulation. 
This  represents  the  time  at  which  the  raw  data  was  collected,  which  is  used  to 
determine  the  utility  decay  due  to  aging 

■  Arrive  Time:  in  the  format  days:  hours  minutes  from  the  start  of  the  simulation 
until  this  job  is  added  to  the  OPCEN  queue 

■  Event  Type:  identifies  the  basic  job  thread 

■  Priority:  identifies  the  priority  of  the  job.  For  the  purpose  of  cross-referencing  to 
the  other  input  files,  the  priority  will  be  rounded  to  the  nearest  value 
corresponding  to  a  basic  job  thread 

■  Deadline:  in  the  format  days:hours:minutes,  used  to  override  (if  desired)  the 
default  slack  time  for  a  specific  event  process.  Enter  00:00:00  to  use  standard 
slack  time 


Figure  22:  03-Events  Example 

•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 
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•  Save  with  the  file  name:  03-Events. txt 

04-SkillsMatrix 

•  The  file  04-SkillsMatrix.txt,  shown  in  Figure  23,  identifies  the  operators  available  for 
tasking,  their  associated  skills  and  performance,  and  their  availability. 

•  Entries  are  in  the  format: 

♦  Operator  Name,  Skill  Focus,  Shift  Hours,  Shift  Days,  %  Speed  of  Work,  %  Quality 

of  Work,  Order  G  Assigned,  %  G  Available,  Skill  1  through  Skill  10 

■  Operator  Name:  a  name  used  to  identify  individual  operators.  All  names  must  be 
unique  within  the  file. 

■  Skill  Focus:  the  primary  skill  set  of  this  operator. 

■  Shift  Hours:  the  number  of  hours  this  operator  works  in  the  assigned  shift. 

■  Shift  Days:  the  number  of  days  this  operator  works  in  a  week. 

■  %  Speed  of  Work:  how  fast  this  operator  works,  with  100%  being  normal.  Faster 
workers  will  have  this  value  set  higher;  slower  workers  will  have  this  value  set 
lower. 

■  %  Quality  of  Work  multiplier:  used  to  modify  the  Utility  value  when  a  product  is 
posted  by  this  operator,  based  on  their  skill. 

■  Order  G  Assigned:  used  to  determine  the  order  in  which  a  generic  (skill  ‘G’)  task 
is  assigned  to  available  operators.  Enter  a  number  between  1  and  the  number  of 
operators.  Each  operator  must  be  assigned  a  unique  ordinal. 

■  %  G  Available:  used  to  identify  the  probability  that  the  associated  operator  will 
be  available  for  generic  steps. 

■  Skill  1  through  Skill  1 0  are  the  skills  in  order  of  preference  for  a  given  operator. 

Note  that  Skill  Focus,  Shift  Hours,  and  Shift  Days  are  currently  unused  in  the  simulation  but  are 
expected  to  be  incorporated  with  further  development. 


Figure  23:  04-SkillsMatrix  Example 
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•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 

•  Save  with  the  file  name:  04-SkillsMatrix.txt 

05-DecayCurves 

•  The  file  05-DecayCurves.txt,  shown  in  Figure  24,  identifies  the  stepwise  decay  of  product 
utility  over  time  as  a  set  of  times  when  the  decay  is  applied  and  the  triangular  distribution  of 
the  remaining  utility  at  that  time. 

•  Entries  are  in  the  format: 

♦  ProductName,  Time,  lowerBound,  Peak,  upperBound 

■  ProductName:  identifies  the  basic  job  thread  and  must  be  one  of  those  defined  in 
input  file  02-ThreadDefinitions 

■  Time:  an  integer  value,  measured  from  the  time  of  observation  (see  Collect  Time 
in  file  03-Events),  when  the  decay  occurs 

■  lowerBound:  an  integer  value  between  0-100  which  identifies  the  lower  bound  of 
a  triangular  distribution 

■  Peak:  an  integer  value  between  0-100  which  identifies  the  mode,  or  peak 
probability,  of  a  triangular  distribution 

■  upperBound:  an  integer  value  between  0-100  which  identifies  the  upper  bound  of 
a  triangular  distribution 

NOTE:  For  each  entry  in  this  file,  the  values  of  lowerBound,  Peak,  and  upperBound  must 
conform  to  the  expression  lowerBound  <  Peak  <  upperBound. 
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□  Microsoft  Excel  -  OPCEN  Init  20090226.xls 
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Figure  24:  O  5 -Dec  ay  Cum’ es  Example 


•  When  saved,  retain  the  header  row  but  ensure  there  are  no  blank  lines  after  the  last  line  of 
text 

•  Save  with  the  file  name:  05-DecayCurves.txt 


A.2.3  Scenario  Development  -  Repository 

The  Repository  folder,  located  beneath  the  primary  scenario  folder,  contains  the  following  files 
used  to  initialize  the  Repository  data  delivery  and  to  provide  information  on  routing,  bandwidth, 
and  probabilities  for  Repository  functions: 

•  Rl-ExtemalData.txt 

•  R2-ExtemalProducts.txt 

•  R3-Delivery.txt 

•  R4-Bandwidth.txt 

•  R5-Questions.txt 

•  R6-DiscoveryRequests.txt 
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•  R7-ExtemalResponse.txt 

Rl-ExternalData 

•  The  file  Rl-ExtemalData.txt,  shown  in  Figure  25,  contains  the  initialization  data  for  the 
delivery  of  external  inputs 

•  Entries  are  in  the  format: 

♦  Job  Number,  Event  Time,  Arrived,  Source,  Type,  Priority,  Deadline,  OPCEN, 
Delivery,  Method,  Size 

■  Job  Number:  must  be  sequential,  starting  at  1 

■  Event  Time:  the  time  at  which  the  data  to  be  analyzed  was  created  (e.g.  for  an 
Imagery  analysis  job,  the  time  at  which  the  image  was  taken) 

■  Arrived:  the  time  at  which  the  data  will  arrive  at  the  Repository 

■  Source:  the  source  used  to  create  the  data.  Currently  unused  by  the  simulation. 

■  Type:  the  type  of  job  thread  that  will  be  triggered  by  the  arrival  of  this  data 

■  Priority:  the  priority  of  the  job  thread  that  will  be  triggered 

■  Deadline:  the  time  at  which  the  job  thread  will  be  abandoned  (00:00:00  indicates 
that  standard  slack  time  for  the  job  type  should  be  used  to  calculate  the  deadline) 

■  OPCEN:  the  OPCEN  that  will  perform  the  job  thread 

■  Delivery:  indicates  whether  the  Repository  will  deliver  the  data  to  the  OPCEN 
via  Push  or  Pull 

■  Method:  whether  the  Push  or  Pull  is  Automated  or  Manual 

■  Size:  the  file  size  of  the  data  that  must  be  delivered 


Figure  25:  Rl-ExtemalData  example 
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R2-ExternalProducts 

•  The  file  R2-ExtemalProducts.txt,  shown  in  Figure  26,  contains  the  initialization  data  for 
delivery  of  external  products.  These  are  the  products  created  by  OPCENs  outside  the 
scenario  but  intended  to  be  used  by  the  scenario. 

•  Entries  are  in  the  format: 

♦  Producing  OPCEN,  Producer’s  Job  Number,  Type,  Specific  Priority,  Size,  Collect 
Time,  Delivery  Time,  Status,  Accrued  Utility,  Decayed  Utility,  Net  Utility 

■  Producing  OPCEN :  the  external  OPCEN  that  created  the  product 

■  Producer’s  Job  Number:  the  job  number  used  by  the  producing  OPCEN  to 
identify  the  specific  product 

■  Type:  the  type  of  job  that  resulted  in  the  product,  including  its  rounded  priority 

■  Specific  Priority:  the  specific  priority  of  the  product 

■  Size:  the  file  size  of  the  product 

■  Collect  Time:  the  time  at  which  the  raw  data  was  collected 

■  Delivery  Time:  the  time  at  which  the  product  will  arrive  at  the  Repository 

■  Status:  the  state  of  completion  of  the  product,  identified  by  the  name  of  the  job 
step  it  has  reached 

■  Accrued  Utility:  the  percentage  of  utility  gained  through  progress  on  the  job 

■  Decayed  Utility:  the  percentage  of  utility  remaining  due  to  the  age  of  the  product 

■  Net  Utility:  the  product  of  Accrued  and  Decayed  Utility 


Figure  26:  R2-ExternaIProducts  Example 


R3-Delivery 

•  The  file  R3-Delivery.txt,  shown  in  Figure  27,  contains  the  initialization  data  for  repository 
routing  of  products  (whether  created  within  the  simulation  or  through  R2-ExternalProducts). 

•  Entries  are  in  the  format: 

♦  Product,  Producer  Echelon,  Producer,  Consumer  Echelon,  Consumer,  Probability, 
Delivery,  Method 

■  Product:  the  product  type,  including  thread  name  and  rounded  priority 
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■  Producer  Echelon:  the  level  of  the  Producer  OPCEN  within  the  command 
structure.  This  is  used  only  for  reference  and  is  ignored  by  the  simulation 

■  Producer:  the  OPCEN  that  may  create  the  product 

■  Consumer:  the  OPCN  that  may  receive  the  product  when  created  by  the  Producer 

■  Consumer  Echelon:  as  with  the  Producer,  this  indicates  the  level  of  the 
Consumer  OPCEN  within  the  command  structure  and  is  used  only  for  reference. 

■  Probability:  the  percent  chance  that  the  Product  will  need  to  be  delivered  to  the 
Consumer  if  created  by  the  Producer 

■  Delivery  and  Method:  as  with  the  External  Data,  these  identify  whether  the 
Product  is  delivered  via  Push  or  Pull,  and  whether  that  delivery  will  be 
Automated  or  Manual 
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Figure  27:  R3-Delivery  Example 
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R4-Bandwidth 

•  The  file  R4-Bandwidth.txt,  shown  in  Figure  28,  contains  the  initialization  data  for 
bandwidth  available  for  repository  routing  of  products. 

•  Entries  are  in  the  format: 

♦  Echelon,  OPCEN,  Bandwidth 

■  Echelon:  the  level  of  the  OPCEN  within  the  command  structure.  Currently 
unused  by  the  simulation. 

■  OPCEN:  identifies  each  OPCEN  that  is  connected  to  the  Repository  in  the 
simulation. 

■  Bandwidth:  the  amount  of  data  (using  the  same  units  as  all  file  size  entries  in  all 
other  input  files)  that  can  be  transferred  between  the  OPCEN  and  the  Repository 
during  one  time  step  (typically  one  minute). 
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Figure  28:  R4-Bandwidth  Example 


R5-Questions 

•  The  file  R5-Questions.txt,  shown  in  Figure  29,  contains  the  initialization  data  for  question 
generation  by  Consumers. 

•  Entries  are  in  the  format: 

♦  Product  Type,  Consumer  OPCEN,  %  Question  Generation,  Question  File  Size, 
Minutes  to  Formulate  Question 

■  Product  Type:  identifies  the  product  received  by  the  consumer 

■  Consumer  OPCEN:  identifies  the  OPCEN  receiving  the  product 
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■  %  Question  Generation:  the  probability  that  the  product  will  cause  a  Question  to 
be  generated 

■  Question  File  Size:  the  size  of  the  file  containing  the  Question,  sent  to  the 
Repository 

■  Minutes  to  Formulate  Question:  the  delay  time  between  the  product  being 
received  and  the  Question  being  raised  by  the  consumer 
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Figure  29:  R5-Questions  Example 
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R6-DiscoveryRequests 

•  The  file  R6-DiscoveryRequests.txt,  shown  in  Figure  30,  contains  the  initialization  data  for 
routing  of  questions  from  the  Repository  to  Discovery.  It  defines  the  probability  of  receiving 
a  response,  and  defines  the  response  received. 

•  Entries  are  in  the  format: 

♦  Question  Type,  Questioning  OPCEN,  %  Response,  Response  File  Size,  Minutes  to 
Get  Response  to  Repository,  Type  of  Response,  Response  Priority 

■  Question  Type:  identifies  the  type  of  product  that  the  Consumer’s  question  is 
based  on 

■  Questioning  OPCEN:  identifies  the  OPCEN  that  submitted  the  question 

■  %  Response:  the  probability  that  a  question  will  be  responded  to 

■  Type  of  Response:  the  basic  job  type  to  invoke  upon  receipt  of  the  response  by  a 
Producer 

■  Response  Priority:  the  priority  of  the  job  to  be  invoked  at  the  producer. 


□  Microsoft  Excel  -  Repository  Init  20090226.xls  |[n)  ><^ 
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Figure  30:  R6-DiscoveiyRequests  Example 
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R7-ExternalResponse 

•  The  file  R7-ExtemalResponse.txt,  shown  in  Figure  31,  contains  the  same  information  as  R6- 
DiscoveryRequests,  except  that  instead  of  being  completed  from  the  perspective  of 
questions  being  sent  to  Discovery,  it  is  done  from  the  perspective  of  queries  sent  to  External 
Sources.  It  also  adds  two  new  entries  between  %  Response  and  Type  of  Response: 

♦  Response  File  Size:  the  size  of  the  file  containing  the  response 

♦  Minutes  to  Get  Response  to  Repository:  the  delay  between  receipt  of  the  question  by 
Discovery  and  receipt  of  a  response  at  the  Repository 


Figure  31:  R7 -ExternalResponse  Example 


A.2.4  Execution 

This  section  describes  the  process  to  run  the  SMOFN  simulation.  It  assumes  that  the  user  has 
some  knowledge  in  CORE  and  has  the  SMOFN  loaded. 

•  Open  the  SMOFN  project 

•  In  the  Project  pane,  select  the  class  OperationalActivity 

•  In  the  Project  pane,  select  the  folder  State  Machine  Sim 

•  In  the  Elements  pane,  select  SM  State  Machine;  the  active  window  should  look  like  Figure 
32 
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Figure  32:  State  Machine  Element  in  CORE 
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•  Under  the  Tools  menu  item,  select  Simulator 

♦  The  Simulator  Control  Panel  opens;  it  should  look  like  Figure  33: 


Figure  33:  Simulator  Control  Panel 

NOTE:  It  is  strongly  recommended  that  the  simulator  output  be  turned  off  for  long  durations  of 
execution.  Do  this  by  selecting  (on  the  Simulator  Control  Panel)  View,  Show  Timeline  Elements, 
and  in  the  resulting  Timeline  Elements  dialog  box,  click  on  Uncheck  All  in  the  Functions  and 
Items  panes. 
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•  On  the  Simulator  Control  Panel,  select  Control,  Run 

♦  Execution  begins  and  the  Open  Data  Path  dialog  box  appears. 

♦  Navigate  to  the  appropriate  folder,  select  the  file  Sl-Datapath.txt,  and  click  the  Open 
button 

♦  A  CORESim  Script  Transcript  window,  shown  in  Figure  34,  opens  and  initialization 
results  are  displayed,  followed  by  execution  processing  of  the  scenario. 


Figure  34:  Simulation  Output  Transcript 

♦  Depending  on  the  length  of  the  scenario,  SimDuration  (simulated  execution  time), 
and  the  numbers  of  events  to  be  processed,  the  simulation  runs  for  seconds  to 
minutes 
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♦  The  simulation  runs  until  the  current  simulation  time  equals  SimDuration,  or  until 
there  are  no  events  left  to  process,  and  it  completes  with  the  message  shown  in 
Figure  35. 


Figure  35:  Simulation  Complete  Dialog 


♦  Click  OK 

♦  The  dialog  box  Model  Changes  Detected,  shown  in  Figure  36,  may  appear 


Figure  36:  Model  Changes  Dialog  Box 


♦  Click  OK 

Suggestion:  Save  the  Transcript  as  a  text  file  at  this  point  so  that  all  events  are  easy  to  correlate 
later.  It  provides  a  good  summary  of  event  times  that  can  be  used  to  process  the  more  detailed  and 
complex  Results  files. 

At  this  point  the  scenario  simulation  is  completed  and  the  Simulator  Control  Panel  can  be  closed 
or  another  scenario  executed. 
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A.2.5  Results 


Seven  results  files  are  created  in  CSV  format  and  would  normally  open  in  Excel. 

Resultsl-Initcsv,  shown  in  Figure  37,  echoes  the  initialization  data  at  the  beginning  of  the 
transcript.  It  can  be  used  for  confirmation  &  troubleshooting  if  unexpected  results  are  found. 


Figure  37:  Results  1 -hut. csv  Example 
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ResuIts2-Operators.csv,  shown  in  Figure  38,  contains  the  current  status  of  each  operator  at  each 
snapshot  interval.  The  first  line  contains  column  headers.  Each  subsequent  entry  contains: 
OPCEN,  current  simulation  time,  operator,  operator  status,  current  tasking  (job  number),  and  the 
skill  that  the  operator  is  currently  using. 
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Figure  38:  Results2-Operators.csv  Example 
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Results3-Events.csv,  shown  in  Figure  39,  contains  the  current  status  of  each  event  at  each 
snapshot  interval.  The  first  line  contains  column  headers.  Each  subsequent  entry  has  the  detail: 
OPCEN,  Job  Number,  Current  Time,  Event  Type,  Event  Priority,  Current  Status,  Accrued  Utility, 
Decayed  Utility,  Net  Utility,  Current  Operator,  Number  of  Operators,  Number  of  Times 
Interrupted,  Estimated  Time  of  Completion,  Drop  Dead  Time,  Slack  Time,  Time  Spent  in  current 
step  or  queue,  Completion  Time,  and  Step  Times  for  each  step  in  the  job  thread.  Each  Step  Time 
has  three  entries:  step  name,  step  start  time  and  step  completion  time. 
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Figure  39:  Results 3 -Events. csv  example 

ResuIts4-Events.Med.csv,  shown  in  Figure  40,  is  formatted  identically  to  Results3 -Events. csv, 
however,  it  contains  only  those  lines  corresponding  to  a  change  in  a  job’s  status. 


Figure  40:  Results4-Events.Med.csv  Example 
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Results5-Events.Short.csv,  shown  in  Figure  41,  is  formatted  identically  to  Results3-Events.csv 
except  that  it  does  not  identify  the  current  operator  or  the  amount  of  time  spent  in  the  current  step 
or  queue.  It  contains  only  the  final  status  for  each  job. 


Figure  41:  Results5-Events.Short.csv  Example 
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Results6-Full.Aggregation.csv,  shown  in  Figure  42,  contains  details  of  the  aggregation  of 
completed  products  into  reports.  The  first  line  contains  column  headers.  Each  subsequent  entry 
contains:  OPCEN,  Aggregated  Job  Number,  Aggregating  Job  Number,  Number  of  Posts  made  to 
the  Repository,  Number  of  Repository  Posts  that  were  expected,  the  Accrued  Utility  that  was 
transferred  to  the  Aggregating  Job,  and  the  Net  Utility  that  was  transferred. 


Figure  42:  Results6-Full.Aggregation.csv  Example 
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Results7-Partial.Aggregation.csv,  shown  in  Figure  43,  contains  the  same  information  as 
Results6-Full. Aggregation  except  that  it  lists  the  details  of  partially  completed  jobs  that  are 
aggregated,  rather  than  finalized  ones. 


Figure  43:  Results7 -Partial.  Aggregation. csv  Example 
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Annex  B  SMOFN  Diagrams 


This  annex  presents  the  Enhanced  Functional  Flow  Block  Diagrams  (EFFBDs)  used  to  control  the 
SMOFN  simulation  sequence  at  all  levels.  Except  for  the  Send  and  Receive  activities  for  the 
Consumer  and  External  Sources,  whose  logic  is  handled  by  the  corresponding  Repository 
activities  (as  noted  in  Section  3.2.5),  all  activities  have  either  lower  levels  of  decomposition  or 
embedded  code.  While  the  decomposition  of  any  operational  activity  is  seen  in  the  subsequent 
diagrams,  the  embedded  code  can  be  provided  electronically. 

Note  that  Figure  44  is  the  top  level  diagram  as  presented  in  Figure  5  of  Chapter  3,  however  it  is 
reproduced  here  without  the  annotation  of  the  individual  phases.  Figure  45  through  Figure  48 
illustrate  larger  scale  views  of  those  phases.  Figure  49  through  Figure  55  illustrate  lower  levels  of 
decomposition  where  any  exists. 
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Figure  44:  SM  State  Machine  EFFBD 
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Figure  46:  OPCEN  Input 
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SM.5 

Generate 

Questions 

Figure  47:  OPCEN  Activity 
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SM.6 


Send  Questions 
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SM 

State  Machine 

Figure  48:  OPCEN  Output  and  Simulation  Output 
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Wednesday,  February  25,  2009 


Setup.  Multi  Node 


Figure  49:  SM.l  Setup. MultiNode  EFFBD 
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Date: 

Thursday,  April  2,  2009 


Thread  &  Queue  Processing 


Figure  50:  SM.12  Thread  &  Queue  Processing  EFFBD 
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Figure  51:  SM.  12. 7  Job  Queue  Processing  Branches  EFFBD 
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Figure  52:  SM.  1 7  Send  from  Repository  EFFBD 
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Figure  53:  SM.18  Receive  at  Repository  EFFBD 
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Figure  54:  SM.22  End-of-Cycle  Reporting  EFFBD 
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Date: 

Monday,  February  26,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

SM.23 

Name: 

End-of-Run  Reporting 

Figure  55:  SM.23  End-of-Run  Reporting  EFFBD 
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Annex  C  Case  1  -  eBrief 


This  Annex  is  included  to  provide  all  of  the  diagrams  that  make  up  the  Electronic  Brief 
preparation  process  model  that  was  described  in  Section  6.1.2.  Where  decision  logic  is  required 
(to  choose  the  correct  exit  branch),  the  COREscript  code  is  included. 


Date: 

Wednesday,  February  21,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

DB 

Name: 

Daily  Brief 

Figure  56:  DB  Daily  Brief  EFFBD 
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Date: 

Wednesday,  February  21,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

DB.l 

Name: 

NLT  2300  SWO  &  OWO  select  Ops  items 

Figure  57:  DB.l  NLT2300  SWO  &  OWO  select  Ops  items  EFFBD 
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Figure  58:  DB.2  Int/CDI  Strat  Inputs  EFFBD 
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Figure  59:  DB.3  Build  E-Brief  EFFBD 


OperatonalActivity  Exit  Logic  Rules: 

DB.3.2  Choose  Mon  vs.  Tue-Sun 

(Script:  Untitled) 

If  (Day  =  'Monday')  Then 

exitLogic  :=  NamedElement  ("Exit",  "Mon") 

Else 

exitLogic  :=  NamedElement  ("Exit",  "Tues  -  Sun") 
Endlf 

Return  (exitLogic) 
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Date: 

Author: 

Tuesday,  January  30,  .. 

DRDC  CORA -J  SORT 

Number: 

Name: 

DB.3.11 

0100-0130  Build  high  level  summary  sli... 

Figure  60:  DB.3.11  0100-0130  Build  high  level  summary >  slides  EFFBD 


DRDC  CORA  TR  2009-012 


Date: 

Author: 

Tuesday, 

January  30,  2007 

DRDC  CORA  -J  SORT 

Number: 

Name: 

DB.3.13 

Publish  high  level  summary  to  CV 

Figure  61:  DB.3.13  Publish  high  level  summary  to  CV EFFBD 
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Date: 

Wednesday,  February  21,  2007 

Author: 

DRDC  CORA  -J  SORT 

Number: 

DB.4 

Name: 

Ops  SITREPS 

Figure  62:  DBA  Ops  SITREPS  EFFBD 


Figure  63:  DB.5  Briefing  Approval  EFFBD 
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OperatonalActivity  Exit  Logic  Rules: 

DB.5.1  Choose  Weekend  vs  Weekday 

(Script:  Untitled) 

If  ((Day  =  'Saturday')  or:  (Day  =  'Sunday'))  Then 
exitLogic  :=  NamedElement  ("Exit",  "Weekend") 

Else 

exitLogic  :=  NamedElement  ("Exit",  "Weekday") 

Endlf 

Return  (exitLogic) 

DB.5.2  Choose  Fri  vs  Mon-Thurs 

(Script:  Untitled) 

If  (Day  =  'Friday')  Then 

exitLogic  :=  NamedElement  ("Exit",  "Friday") 

Else 

If  (((Day  =  'Monday')  or:  (Day  =  'Tuesday'))  or:  ((Day  =  'Wednesday')  or:  (Day  = 
'Thursday')))  Then 

exitLogic  :=  NamedElement  ("Exit",  "Mon-Thurs") 

Else 

Breakpoint 

COMMENT:  Invalid  Day 
Endlf 
Endlf 

Return  (exitLogic) 
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Date: 

Wednesday.  February  21.  2007 
Number: 

DB.6 


Author: 


DRDC  CORA  -  J  SORT 


CDS  Briefing 


Figure  64:  DB.  6  CDS  Briefing  EFFBD 

OperatonalActivity  Exit  Logic  Rules: 

DB.6.1  Choose  Fri  vs  Sat-Thurs 

(Script:  Untitled) 

If  (Day  =  'Friday')  Then 

exitLogic  :=  NamedElement  ("Exit",  "Thurs  evening  for  Fri  brief') 
Else 

exitLogic  :=  NamedElement  ("Exit",  "Sat  -  Thurs") 

Endlf 

Return  (exitLogic) 
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Date: 

Tuesday,  January  30,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

DB.7 

Name: 

Other  E-Portions 

Figure  65:  DB.  7  Other  E-Portions  EFFBD 


OperatonalActivity  Exit  Logic  Rules: 

DB.6.1  Choose  Fri  vs  Sat-Thurs 

(Script:  Untitled) 

If  (Day  =  'Friday')  Then 

exitLogic  :=  NamedElement  ("Exit",  "Thurs  evening  for  Fri  brief') 
Else 

exitLogic  :=  NamedElement  ("Exit",  "Sat  -  Thurs") 

Endlf 

Return  (exitLogic) 
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Figure  67:  DB.7.3  CF personnel  deployed  inputs  check  EFFBD 


Figure  68:  DB.8  Briefing  Dissemination  EFFBD 

OperatonalActivity  Exit  Logic  Rules: 

DB.8.1  Choose  Mon,  Tue,  Thu,  Fri  vs  Sat,  Sun,  Wed 

(Script:  Untitled) 

If  (((Day  =  'Saturday')  or:  (Day  =  'Sunday'))  or:  (Day  =  'Wednesday'))  Then 
exitLogic  :=  NamedElement  ("Exit",  "Wed,  Sat,  Sun") 

Else 

exitLogic  :=  NamedElement  ("Exit",  "Mon,  Tue,  Thur,  Fri") 

Endlf 

Return  (exitLogic) 
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Figure  69:  DB.9  2000-0800  EFFBD 
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Annex  D  Case  2  -  Casualty  Reporting 


This  Annex  is  included  to  provide  all  of  the  diagrams  that  make  up  the  International  Casualty 
Reporting  process  model  that  was  described  in  Section  6.2.2. 


Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA  -  J  SORT 

Number: 

IP 

Name: 

Action  in  the  Event  of  Death/Serious  Injury  -  International  Ops  -  Parallel  Processing 

Figure  70:  IP  Action  in  the  Event  of  Death/Serious  Injury >  -  International  Ops  -  Parallel 

Processing  EFFBD 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA  -  J  SORT 

Number: 

IP.l 

Name: 

SER  1-8  -  HR  or  Cas 

Figure  71:  IP.l  SER  1-8  -  HR  or  Cas  EFFBD 
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Figure  72:  IP.  1.1:  Deployed  Ops  Activities  EFFBD 


106 


DRDC  CORA  TR  2009-012 


Figure  73:  IP. 1.2  CEF COM  Activities  EFFBD 
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Date: 

Author: 

Thursday,  February  15,  2007 

DRDC  CORA-  J  SORT 

Number: 

Name: 

IS. 4.6 

conduct  IOPG  and  follow-ups  as  required 

Figure  74:  ISA. 6  conduct  IOPG  and  follow-ups  as  required  EFFBD 


Thursday,  February  15,  2007 


Figure  75:  IP.  1.3  NDCC  Activities  EFFBD 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA- J  SORT 

Number: 

1  P.1.4 

SJ  S  Activities 

Figure  76:  IP.  1.4:  SJS  Activities  EFFBD 


Figure  77:  IP.  1.5  CANOSCOM  Activities  EFFBD 
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Thursday,  February  15,  2007 


COMDS  /  ECS  /  LI  Activities 


Figure  78:  IP.  1.6  COMDS  /  ECS  /  LI  Activities  EFFBD 
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Figure  79:  IP.l.  7  NMR  Activities  EFFBD 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA -J  SORT 

Number: 

IP. 3 

Name: 

SER  9  -  HR 

Figure  80:  IP.  3  SER  9  -  HR  EFFBD 


112 


DRDC  CORA  TR  2009-012 


Date: 

Author: 

Thursday,  February  15,  2007 

DRDC  CORA -J  SORT 

Number: 

Name: 

1  P.5 

SER  10  -  HR 

Figure  81:  IP.  5  SER  10 -HR  EFFBD 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA  -  J  SORT 

Number: 

1  P.8 

Name: 

SER  10  -  Cas 

Figure  83:  IP.  8  SER  10  -  Cas  EFFBD 
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Date: 

Thursday,  February  15,  2007 

Author: 

DRDC  CORA  -J  SORT 

Number: 

1  P.9 

Name: 

SER  11-12  -  HR  or  Ca 

Figure  84:  IP.  9  SER  11-12  -  HR  or  Cas  EFFBD 
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Annex  E  Future  SOP  Considerations 


The  following  SOPs  have  been  identified  by  operators  as  good  candidates  for  modelling  in  CORE 
and  conversion  to  SMOFN  inputs,  as  described  in  Chapter  6: 

E.1  SME  Proposed  SOP  Threads 

The  following  activities  are  partially  modelled  through  SME  interviews,  but  must  be  validated: 

1 .  RFI  process  for  CDI  and  for  Ops 

2.  OSINT/OSINF 

3.  JCDS21  12  processes 

4.  CFEC  Guardian 

E.2  SJS  NDCC  Proposed  SOPs 

The  following  SJS  NDCC  SOPs  have  been  proposed  for  modelling  and  validation: 

1.  Daily  e-brief:  NDCC  version  has  been  described  and  validated  by  SME,  repeat  for  all 
Commands  and  link  for  interactions 

2.  Casualty/EIR:  Inti  Ops  SOP  matrix  has  been  reviewed  and  validated  by  SME,  repeat  for 
versions  from  Canada  COM  &  Domestic  Ops 

3.  Incident/Event  Reporting 

4.  Main  operational  event  to  trigger  other  activities 

5.  Staff  Action  Teams  (Crisis  OPP) 

6.  Initial  response  (High  Fidelity) 

7.  Follow-on  activities  (Lower  Fidelity) 

8.  NORAD  Responsibilities  &  SOPs  (classified  version) 

9.  Commander’s  Critical  Intelligence  Requirement 

10.  Deliberate  planning 

1 1 .  Other  briefs 
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E.3  JIIFC  Det  proposed  SOPs 

The  JIIFC  Det  has  proposed  the  following  SOPs  for  modelling: 

1.  Visits  to  theatre  (i.e.  JTF  AFG) 

2.  J4  Log  tracking 

3.  J1  -  J9  cooperation 

4.  Data  Transfer 

5.  OPCEN  support  to  Commands 
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List  of  symbols/abbreviations/acronyms/initialisms 


AAR 

After  Action  Report 

APOD 

Airport  of  Disembarkation 

C2 

Command  and  Control 

Cas 

Casualties 

CDS 

Chief  of  the  Defence  Staff 

CEFCOM 

Canadian  Expeditionary  Forces  Command 

CF 

Canadian  Forces 

CFACC 

Combined  Forces  Air  Component  Command 

CFOCC 

Canadian  Forces  Operations  Centre  Conference 

Comd 

Commander 

CORA 

Centre  for  Operational  Research  and  Analysis 

DND 

Department  of  National  Defence 

DNDAF 

DND/CF  Architecture  Framework 

DoDAF 

Department  of  Defense  Architecture  Framework 

DRDC 

Defence  Research  &  Development  Canada 

eBrief 

Electronic  Briefing 

ECS 

Environmental  Chiefs  of  Staff 

EFFBD 

Enhanced  Functional  Flow  Block  Diagram 

GUI 

Graphical  User  Interface 

HR 

Human  Remains 

IC2S 

Integrated  Command  and  Control  System 

JCDS21 

Joint  Command  Decision  Support  for  the  21st  Century 

JSORT 

Joint  Studies  Operational  Research  Team 

LE 

Loop  Exit 

LP 

Loop 

MARLANT 

Maritime  Forces  Atlantic 

MBCE 

Model-Based  Capability  Engineering 

MSOC 

Marine  Security  Operations  Centre 

NAPP 

National  Aerospace  Planning  Process 

NDCC 

National  Defence  Command  Centre 
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NLT 

No  Later  Than 

NSTR 

Nothing  Significant  to  Report 

OPCEN 

Operations  Centre 

OV 

Operational  View 

OWO 

Operations  Watch  Officer 

SA 

Situational  Awareness 

SITREP 

Situation  Report 

SJS 

Strategic  Joint  Staff 

SM 

State  Machine 

SME 

Subject  Matter  Expert 

SMOFN 

State  Machine  of  Federated  Nodes 

SOP 

Standard  Operating  Procedure 

swo 

Senior  Watch  Officer 

TPED 

Task,  Process,  Exploit,  Disseminate 

TPPU 

Task,  Post,  Process,  Use 

VKB 

Virtual  Knowledge  Base 

VV&A 

Verification,  Validation,  and  Accreditation 

NOTE 

Acronyms  used  in  the  diagrams  of  the  Annexes  are  NOT  listed  because 
specific  model  content  is  incidental  to  the  issues  discussed  in  this  report. 
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Glossary 


Federated 

Several  smaller  entities  operating  as  one  large  interconnected  entity.  We  consider  the 
operational  concept  of  federated  nodes,  while  the  system  equivalent  would  be  a  federated 
database  [1],  It  stands  to  reason  that  the  physical  implementation  of  the  Repository,  which  is 
shared  by  the  federated  nodes,  would  be  a  federated  database. 


Job 


A  series  of  steps  by  one  or  more  operators.  The  result  of  each  instance  of  each  job  is  a  unique 
product.  For  example,  if  an  OPCEN  produces  several  SITREPs,  the  production  of  each  one  is 
a  separate  instance  of  a  SITREP  job. 

Node 

A  logical  operational  entity.  It  is  used  at  multiple  levels  of  abstraction  such  as  the  different 
roles  performed  by  an  OPCEN  (Producer,  Consumer,  etc.),  of  the  OPCENs  themselves,  or  of 
the  different  roles  within  the  chain  of  command. 

Post 

The  act  of  storing  the  new  information  produced  from  a  job  step.  The  post  may  occur  one  or 
more  times  within  a  job  step  but  must  occur  at  the  end  of  each  step. 

Slack  time 

The  amount  of  time  that  a  job  can  be  delayed  and  still  be  completed  on  time. 

State  Machine 

“Any  device  that  stores  the  status  of  something  at  a  given  time  and  can  operate  on  input  to 
change  the  status  and/or  cause  an  action  or  output  to  take  place  for  any  given  change.”  [4] 

Step 

Jobs  are  divided  into  a  series  of  steps.  In  the  SMOFN,  each  step  can  have  a  different  skill 
requirement,  duration,  amount  of  utility  contributed,  and  number  of  posts.  There  is  always  a 
post  of  the  interim  or  completed  product  into  the  repository  at  the  end  of  each  step. 

Thread 

Similar  to  a  job  except  that  the  context  is  different.  A  thread  focuses  on  describing  the  series 
of  steps  performed  whereas  the  job  focus  is  on  the  output. 
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